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FOREWORD 

The  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences  (ARI) 
maximizes  combat  effectiveness  through  research  In  the  acquisition, 
development,  training,  and  utilization  of  soldiers  In  military  systems.  The 
ARI  Field  Unit  at  Ft  Leavenworth  supports  the  Combined  Arms  Center  by 
developing  research  products  designed  to  Increase  the  combat  effectiveness  of 
command  groups  and  command  staff  operations  by  Improving  command  and  control 
performance  capabilities.  Of  special  Interest  is  research  in  the  use  of 
automation  to  Improve  command  and  control  operations. 

The  Combined  Arms  Center  is  responsible  for  integrating  efforts  to  develop 
automated  command  and  control  systems,  to  Include  informal  efforts, 
characterized  as  field  unit  initiatives.  The  Army  Command  and  Control 
Initiatives  Program  (TACIP)  was  established  to  capitalize  on  the  experience 
and  lessons  learned  of  field  units  experimenting  in  automation.  As  the 
various  Corps  and  Division  initiatives  got  underway  one  common  problem  began 
to  emerge.  This  involved  the  lack  of  readily  available  practical  guidance  on 
how  to  go  about  the  system  development  process  within  the  context  of  command 
and  control  operations.  In  response  to  this  need,  the  Combined  Arms  Center 
requested  that  ARI  summarize  the  findings  of  their  past  and  ongoing  projects 
in  order  to  develop  guidelines  for  automating  command  and  control  functions  in 
field  units.  The  product  would  be  a  manual  that  would  describe  known  concepts 
and  principles  useful  to  field  units  in  their  desire  to  develop  automation 
support  for  command  and  control.  It  is  towards  this  end  that  this  document 
was  developed.  More  specifically,  this  document  ^escribes  the  command  and 
control  process  in  information  system  terms.  V.i  nation  system  tools  and 
techniques  are  described  and  discussed  to  show  their  utility  in  guiding 
selected  changes  to  the  procedures,  organization,  personnel  and  technological 
components  of  the  command  and  control  system  in  order  to  enhance  its 
effectivness.  The  guidelines  presented  were  designed  to  assist  field  users  in 
smoothing  the  transition  to  new  systems  by  providing  insights  into  the  problem 
of  building  man-machine  systems  which  take  full  advantage  of  all  system 
components,  and  by  providing  tools  which  can  be  used  to  accomplish  the 
necessary  system  integration. 

The  application  of  principles  set  forth  in  this  document  will  assist  users 
in  achieving  more  quickly  the  improved  command  and  control  performance 
standards  inherent  in  Future  Battle  Doctrine. 


Chief  Psychologist,  US  Army 


HO'NARD  P.  WISH  ART  III - 

Major  General,  USA 
Deputy  Commander 
US  Army  Combined  Arms  Combat 
Development  Activity 


iii 


EXECUTIVE  SUMMARY 


This  manual  has  been  prepared  to  assist  officers  in  the 
field  who  are  wrestling  with  the  problem  of  incorporating  automa¬ 
tion  into  command  and  control  functions  in  an  endeavor  to  meet 
the  significantly  improved  performance  standards  inherent  in  the 
Airland  Battle  Doctrine.  It  is  based  on  the  experience  of  others 
who  have  already  been  involved  in  that  endeavor.  It  contains 
information  that  should  be  useful  to  commanders,  staff  officers 
and  especially  the  project  officers  charged  with  the  task  of 
overseeing  the  introduction  of  computer  support  into  units  in  the 
field.  It  is  not  designed  to  teach  the  elements  of  computer 
programming  or  software  design.  Experts  can  be  found  to  do  those 
tasks.  Rather,  it  is  designed  to  provide  insights  into  the 
problem  of  building  man-machine  systems  which  take  advantage  of 
new  tools  that  provide  previously  unavailable  capabilities  to 
help  tactical  decision  makers  in  their  performance  of  command  and 
control  operations.  It  cannot  at  this  stage  be  as  detailed  or 
prescriptive  as  a  maintenance  manual  or  even  a  manual  on  tactical 
operations.  In  effect,  your  unit  is  about  to  embark  on  an  exper¬ 
iment  to  find  out  how  automation  can  best  assist  you.  It  does, 
however,  provide  suggestions  and  describes  some  techniques  which 
can  assist  you  in  conducting  this  experiment  in  a  rational, 
effective  manner. 

This  manual  consists  of  three  sections.  The  first  is  a 
brief  introduction.  Section  2  is  the  "How  to"  portion  of  the 
manual.  Described  in  it  are  basic  principles  that  apply  to  the 
introduction  of  computer  support  into  information  systems  in 
general,  and  to  military  systems  in  particular.  It  is  the  dis¬ 
tillation  of  experiences  of  Tactical  Command  and  Control  Initia¬ 
tives  Program  (TACIP)  participants  and  participants  in  other 
Army,  OSD,  and  private  sector  automation  programs.  Ejection  3  is 
a  description  of  the  tactical  command  and  control  (Cz)  system  in 
information  system  terms.  The  description  proceeds  by  postulat¬ 
ing  and  answering  nine  questions  about  the  tactical  Cz  system. 
In  doing  so  a  model  of  the  operations  of  a  TOC  in  information 
processing  terms  is  developed  for  use  as  a  descriptive  tool  in 
designing  a  combined  man-machine  system  which  will  exploit  com¬ 
puter  support  to  facilitate  and  improve  Cz  performance.  The 
parallel  between  this  model  and  the  decision  process  described  in 
FM  101-5  is  stressed.  A  general  discussion  is  also  provided  of 
some  needed  improvements  in  CZ  and  points  out  how  automation  can 
help  implement  these  needed  improvements.  Section  3  was  included 
for  those  officers  who  may  be  unfamiliar  with  information  system 
theory  and  terminology.  Review  of  it  provides  the  foundation  or 
basis  for  more  thorough  understanding  of  the  principles  and 
concepts  discussed  in  Section  2.  This  discussion  of  "theory"  was 
intentionally  placed  after  the  "practice"  material  to  allow 
readers  already  familiar  with  the  theory  to  proceed  directly  to 
the  substance  of  the  manual. 
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Section  2,  as  pointed  out  above,  is  the  practical  appli¬ 
cation  part  of  the  manual.  It  begins  with  a  horrible  example  of 
automation  in  the  home  which  violates  every  precept  of  successful 
and  acceptable  application  of  a  computer  support.  It  then  lays 
out  a  series  of  operational  principles  which  must  be  followed  if 
the  implementation  of  automated  support  is  to  be  successful  and 
accepted  in  tactical  units.  Following  these  general  principles 
permits  implementation  of  the  system  development  cycle  shown  in 
the  figure  below.  This, cycle  represents  a  systematic  methodology 
for  conducting  field  C*  system  experimentation.  Improved  goals 
for  C£  are  identified,  candidate  applications  -  of  manageable 
size  or  broken  down  into  a  series  of  steps  each  of  which  is 
doable  within  time  and  resource  constraints  -  are  defined  and 
prioritized.  The  applications  are  then  developed  and  tested  to 
determine  whether  or  not  improvement  goals  have  been  met.  The 
improved  system  then  becomes  the  baseline  for  enhancements  that 
will  be  designed  in  the  next  iteration  of  the  cycle. 
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DEVELOPMENT  CYCLE 


Section  2  then  goes  on  to  discuss  the  kinds  of  assets 
required  to  prosecute  this  kind  of  an  effort  and  then  suggests 
some  possible  sources  for  this  kind  of  expertise.  Especially 
stressed  is  the  need  for  the  rare  individuals  who  have  both 
military  experience  and  staff  training  as  well  a  sufficient 
technical  knowledge  to  enable  them  to  converse  intelligently  with 
the  technicians  who  have  the  required  expertise  in  hardware  and 
software.  A  number  of  our  younger  officers  have  this  rare  combi¬ 
nation  of  skills  in  sufficient  degree  so  they  can  translate 
between  military  and  computer  expertise,  thus  greatly  facilitat¬ 
ing  the  effort.  A  suggested  ad  hoc  organization  to  carry  out 
this  effort  is  described.  Also  discussed  are  a  number  of  en¬ 
abling  principles  which  should  help  in  carrying  out  the  effort. 
These  are  incorporated  into  a  "road  map"  which  lays  out  the  five 
phases  of  the  development  cycle  and  13  tasks  that  need  to  be 
performed.  Techniques  for  performing  a  number  of  these  tasks  are 
discussed.  The  section  concludes  with  the  reminder  that  the 
whole  object  of  the  procedures  is  to  gain  initial,  and  to  main¬ 
tain  continuing  acceptance  of  the  new  modes  of  operation  that 
will  inevitably  evolve  from  incorporating  automated  support.  A 
set  of  precepts  which  summarize  the  manual  and  are  based  on  the 
experience  of  others  is  stated;  these  include: 

•  You  must  inspire  confidence  in  the  ability  of 
automated  support  to  assist  you  in  tactical 
operations . 

•  You  must  avoid  even  the  appearance  of  adding 
to  the  workload. 

•  You  must  overcome  "computer  anxiety"  by  expos¬ 
ing  the  ultimate  operators  to  the  equipment  as 
early  as  possible. 

•  You  must  have  adequate  technical  expertise  avail¬ 
able;  this  is  part  and  parcel  of  sizing  your 
application  to  fit  available  resources. 

•  While  not  letting  communication  difficulties  unduly 
affect  your  initial  trials,  you  must  be  ever  aware 
of  the  ultimate  constraints  imposed  by  your  commo 
net. 
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SECTION  1 


INTRODUCTION 


1.1  WELCOME  TO  THE  CLUB 

So  your  unit  is  considering  the  selection  of  data  pro¬ 
cessing  equipment  to  see  how  it  can  be  used  to  improve  tactical 
operations  in  the  field  --  and  you,  whether  you  are  the 

•  Commander 

•  Head  of  the  lead  staff  section,  or 

•  Project  Officer 

are  the  guy  stuck  with  making  it  work.  Well,  welcome  to  the 
club;  you  are  not  alone  —  others  have  been  and  are  charged  with 
similar  responsibilities  in  other  units.  All  of  you  have  one 
major  factor  going  for  you;  you  are  experienced  tactical  decision 
makers  who  understand  staff  procedures  at  your  echelon.  You  are 
keenly  aware  that  the  tactics  visualized  in  Airland  Battle  doc¬ 
trine  require  a  clarity  of  perception,  recognition  of  opportu¬ 
nities  for  exercising  your  initiative,  and  degree  of  responsive¬ 
ness,  that -seem  unachievable  with  the  current  manual  command  and 
control  ( c  )  system.  You  have  the  gut  feeling  that,  somehow, 
computer  support  could  help  you  achieve  goals  such  as: 

•  Reducing  the  lag  time  between  the  occurrence  of 
battlefield  events  and  your  recognition  of  those 
events  (particularly  delays  in  your  own  HQs) . 

•  Assist  the  staff  by  reducing  and  spreading  out  the 
peak  workloads  associated  with  the  morning  and 
evening  briefings. 

•  Speed  and  improve  the  estimate  process  by: 

Providing  memory  aids  which  permit  con¬ 
sideration  of  more  alternatives 

Providing  a  war  gaming  capability 

for  better  evaluation  of  alternatives 

Providing  better  and  more  rapid  extra¬ 
polations  of  current  trends 

Providing  more  rapid  dissemination 
of  only  that  hard  copy  needed  by  the 
staff 

•  Speed  the  implementation  of  decisions  by  performing 
many  of  the  time  consuming  calculations  needed  to 


transform  a  concept  of  operations  into  an  opera¬ 
tions  order. 


And  the  list  goes  on  and  on.  B>  v  you  also  know  intuitively  that 
the  mere  addition  of  computer  hardware  and  software  will  not 
miraculously  achieve  such  goals.  Somehow  these  tools  must  be 
integrated  into  TOC  operations  to  create  a  man-machine  system 
that  takes  advantage  of  the  unique  capabilities  of  both  and 
avoids  their  respective  limitations. 

1.2  PURPOSE 

It  is  the  purpose  of  this  manual  to  assist  you  in  this 
effort  by  making  available  to  you  the  experience  of  others  who 
have  wrestled  with  the  problem  of  introducing  automation  into 
operations,  be  they  military  or  industrial.  It  is  not  a  "how  to" 
manual  designed  to  teach  you  the  elements  of  computing  program¬ 
ming  or  software  design.  You  can  find  experts  to  do  that  for 
you.  It  is  designed  to  provide  insights  into  the  problem  of 
building  man-machine  systems  which  take  advantage  of  new  tools 
that  provide  previously  unavailable  capabilities  to  perform 
command  and  control  operations. 

The  figure  below  shows  in  shorthand  form  what  this 
manual  contains  and  options  which  are  available  to  you  for  pro¬ 
ceeding  with  your  review  of  those  contents.  Following  this 


Organization  of  Manual  and  Options  for  Proceeding 


introduction,  there  are  two  major  additional  sections.  Section  2 
is  the  "How  to"  portion  of  this  manual.  It  provides  certain 
basic  principles  that  apply  to  the  introduction  of  computer 
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support  into  information  systems,  in  general,  and  to  military 
systems  in  particular.  It  is  the  distillation  of  experience  of 
others  in  absorbing  this  new  technology.  To  effectively  utilize 
the  material  contained  in  Section  2,  however,  requires  that  you 
have  a  thorough  familiarity  with  basic  notions  of  information 
systems  theory  and  how  the  tactical  Cz  system  fits  within  the 
context  of  this  theory.  This  general  theoretical  content  is  what 
is  contained  in  Section  3.  It  is  for  this  reason  that  the  figure 
directs  you  to  Section  3  after  you  have  completed  this  introduc¬ 
tion.  You  should  scan  Section  3  in  order  to  make  a  decision; 
i.e.,  "yes",  I  need  to  review  this  material  before  going  on  to 
Section  2  or  "no"  I  know  this  material  and  review  is  unnecessary. 
We  built  in  this  option  or  decision  strategy  to  insure  that  we 
did  not  force  already  knowledgeable  readers  to  wade  through  the 
theory  before  getting  into  the  practical  applications  arena.  Be 
sure  that  you  are  familiar  with  Section  3's  contents.  Otherwise, 
you  will  not  share  the  same  frame  of  reference  from  which  Section 
2's  contents  were  developed. 


SECTION  2 


HOW  TO  ORGANIZE  THE  EFFORT 


At  this  stage  of  our  experience  with  automation,  you 
probably  realize  that  our  knowledge  of  how  to  do  this  is  still 
inadequate  to  write  a  complete,  step-by-step  "How  to"  manual. 
You  have,  in  effect,  been  charged  with  conducting  an  experiment 
in  improving  tactical  operations  in  your  command  by  providing 
computer  support  to  appropriate  tasks  performed  by  the  commander 
and  his  staff.  It  is  the  purpose  of  this  section  to  provide  some 
suggestions,  lay  out  some  tasks,  and  describe  some  techniques 
which  will  assist  you  in  performing  this  experimentation  in  a 
rational,  effective  manner. 

The  remainder  of  this  section  is  organized  as  outlined 

below: 
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The  following  excerpt  provides  an  object  lesson  in  what 
happens  when  you  ignore  some  of  the  basic  rules  for  the  introduc¬ 
tion  of  automation. 


WASHINGTON  POST,  14  JULY  1983 

CAPITOL  PUNISHMENT  SOFTWARE , SHMOFTWARE1  by  Art  Buchwald 

The  home  computer  business  is  in  a  lot  of  trouble.  It 
would  be  nice  to  blame  the  Japanese  for  it  all,  but  they  never 
really  got  into  the  action. 

One  of  the  reasons  that  business  got  into  difficulty  is 
the  female  gender  problem.  Women  still  don't  appreciate  the 
value  of  a  home  computer  and  what  it  can  do  to  make  their  lives 
easier . 

When  I  set  up  by  brand-new  computer  one  night,  my  wife 
asked  why  I  bought  it. 

"This  is  going  to  change  our  lives.  We  can  do  our  taxes 

on  it." 

"H&R  Block  did  them  already." 

"Well,  we  can  do  them  next  year,"  I  said.  "We  also  can 
compute  our  household  expenses  on  this  machine.  Give  me  all  our 
bills  and  I’ll  start  programming  them." 

"You  have  to  be  kidding.  It  will  take  me  three  months 
to  find  all  our  bills.  Would  you  take  my  word  for  it  that  we 
spent  $10,000  more  than  you  made  in  1982?" 

"All  right,  I’ll  put  that  into  the  computer." 

"What  does  the  computer  say  about  that?" 

"It  says  we  spent  $10,000  more  than  I  made.  Why  don't  I 


try  balancing  your  checkbook?  Give  me  all  your  stubs." 

"What  for?" 

"The  bank's  computer  could  have  made  a  mistake  and  we 
can  take  our  computer  printout  to  the  president  and  show  it  to 
him." 

She  came  back  and  threw  her  check  stubs  on  my  desk  and 
stomped  out  of  my  study. 

Three  hours  later  she  came  back.  "How  are  you  doing?” 

"I’m  up  to  Lord  &  Taylor's  stub  for  March.  So  far 
everything  checks  out.  Maybe  I'll  make  up  your  calendar  for  the 
week.  What  have  you  got  on  for  the  next  few  days?" 

"I  have  a  hairdresser's  appointment  on  Thursday". 

"Good,  now  I'll  just  feed  that  information  into  the 
computer,  and  then  when  you  want  to  know  what  you  have  got  on  for 
Thursday,  you  must  put  this  floppy  disk  into  this  slot,  put  your 
finger  on  CODE,  then  hit  this  button,  and  you'll  know  you  have  a 
hairdresser's  appointment  on  Thursday." 

"I  already  know  it." 

"Okay,  forget  the  calendar.  Let's  take  an  inventory  of 
everything  we  have  in  the  house." 

"At  11  o'clock  at  night?" 

"Why  not?  Once  we  record  it  on  a  disk,  and  we  have  a 
fire,  we'll  know  what  was  lost." 

"Suppose  the  computer  gets  burned  up  in  the  fire?" 

"We  won’t  keep  the  disk  in  the  house.  We'll  put  it  in 
my  office,  and  a  printout  in  the  bank's  safety  deposit  box." 

"What  else  can  your  computer  do?" 

"I  can  key  into  a  bulletin  board  and  talk  to  anyone  in 
the  United  States  who  has  a  compatible  communications  terminal." 

"You  can  do  that  by  phone.  You  still  haven't  told  me 
why  you  bought  this  computer." 

"If  you  must  know,  I  bought  it  for  the  children.  Kids 
have  to  grow  up  these  days  with  computer  knowledge." 

"Our  children  are  all  grown  up  and  they  don’t  live  here 

anymore . " 


"You  never  know  when  they'll  come  back  home." 

The  home  computer  is  still  in  my  study,  but  I  don't  seem 
to  use  it  as  much  as  I  thought  I  would.  I  made  a  friend  in 
Minneapolis  with  it  one  night,  but  just  when  we  were  getting  to 
know  each  other,  his  wife  made  him  come  to  bed. 


2.2  PERSONNEL  AND  ORGANIZATION 

The  following  suggestions  are  based  on  observations  of 
and  disucssions  with  units  in  the  field  which  have  already  wres¬ 
tled  with  the  problem  of  incorporating  automation  into  their 
tactical  operations.  They  include  the  concepts  that  seem  to  have 
worked  best  in  organizing  the  required  personnel  and  skills. 
Since  the  object  is  to  provide  support  to  the  commander's  deci¬ 
sion  making,  i.e.,  an  integrating  system,  the  effort  does  not 
fall  totally  within  the  province  of  any  single  staff  section  or 
special  support  group  (e.g.,  AMO). 

As  in  organizing  any  such  wide-ranging  effort,  the  key 
factor  is  getting  the  right  people  assigned,  people  with  the 
required  interest,  skills,  and  time  to  devote  to  it.  Basically, 
three  different  groups  of  personnel  are  of  concern  for  this 
effort: 

•  The  Users:  These  must  include: 

The  commander  and  senior  staff  who  are 
the  ultimate  users  of  the  tactical  infor¬ 
mation  system  and  will  be  the  principal 
beneficiaries  of  improvements  in  staff 
operations . 

Other  members  of  the  staff  whose  activi¬ 
ties  will  be  affected  or  changed  by 
computer  support. 

•  The  Technicians:  These  are  the  experts  in  both 
hardware  and  software.  They  know,  in  a  technical 
sense,  both  the  capabilities  and  limitations  of 
automation . 

e  The  Change-Agents:  These  are  those  few  rare  indi¬ 
viduals  who  can  speak  both  "militarese"  and  "com¬ 
puterese"  and  thereby  facilitate  communication 
between  the  first  two  above. 

Of  the  three  classes  of  personnel  cited,  the  technicians 
are  the  most  obvious  shortfall  in  your  current  TOE.  There  are 
three  possible  sources  for  such  hardware  and  software  expertise: 
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•  The  Force  Modernization/Force  Development  (FM/FD) 
personnel  assigned  to  your  unit. 

e  The  Automation  Management  Office  or  Officer(s) 

(AMO)  assigned  to  your  unit. 

e  Contractor  support. 

The  first  two  groups  named  above  operate  differently  in  different 
commands,  so  you  will  have  to  adjust  your  requests  to  the  local 
ground  rules.  FM/FD  personnel  have  been  trained  in  system  analy¬ 
sis  and  may  or  may  not  have  extensive  ADP  experience  in  their 
backgrounds.  AMO  personnel,  on  the  other  hand,  have  definitely 
had  extensive  training  and  experience  in  automation.  Although 
they  have  been  primarily  concerned  with  some  of  the  large,  cen¬ 
tralized  data  processing  systems,  they  can  also  be  of  assistance 
in  the  development  of  automated  support  to  the  tactical  Cz  sys¬ 
tems.  Funding  for  contractor  assistance  is  available  to  USAREUR 
units  from  the  CINC  Initiatives  Program  and  from  TRADOC/CACDA  at 
Fort  Leavenworth.  CONUS  units  can  obtain  such  funding  from 
TRADOC/CACDA . 

Of  the  three  groups  of  personnel  cited  above,  the  last 
—  the  change-agents  — ,  although  the  smallest  in  number,  is  in 
many  ways  the  key  ingredient  because  it  forms  the  bridge  between 
the  first  two.  The  successful  implementation  of  computer  support 
to  the  Cz  system  is  a  classic  example  of  the  joint  effort  of  two 
completely  different  kinds  of  expertise.  Only  the  military 
expert  understands  the  true  nature  of  what  the  system  is  trying 
to  accomplish  and  its  operating  environment  —  to  include  the 
limitations  of  human  processors  with  which  he  is  only  too  famil¬ 
iar.  The  technical  expert  in  hardware  and  software,  on  the  other 
hand,  is  completely  familiar  with  the  capabilities  and  limita¬ 
tions  of  automation  but  has  difficulty  expressing  these  in  the 
operational  terms  familiar  to  the  military  expert.  Getting  these 
two  groups  to  communicate  is  the  real  key  to  producing  a  useful 
system  design  which  is  acceptable  to  the  user.  This  process  can 
be  expedited  by  making  available  the  few  individuals  who  have 
even  limited  expertise  on  both  sides  of  the  fence.  Such  an 
individual  is  often  called  a  change-agent.  Frequently  this  will 
be  an  officer  who,  even  though  he  is  relatively  junior  and  has 
limited  staff  experience,  has  had  enough  exposure  to  automation 
so  that  he  can  talk  to  the  technicians.  Such  an  individual  can 
act  as  expediter  or  catalyst  to  get  the  dialog  between  military 
and  technical  experts  started  and,  in  effect,  to  translate  from 
one  set  of  expertise  into  the  other.  Here  again,  top-down  or 
command  emphasis  is  the  key  to  making  this  rare  resource  avail¬ 
able  even  on  an  ad  hoc  basis. 

Figure  2-1  shows  one  suggested  way  in  which  personnel 
from  the  above  groups  can  be  organized.  It  shows  a  steering 
committee  and  a  project  officer  with  direct  access  to  the  office 
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of  the  CG/CS.  The  steering  committee  is  chaired  by  the  CG/CS; 
members  include  the  coordinating  staff  chiefs  and  the  project 
officer.  The  latter  can  be  accompanied  by  the  senior  technical 
person.  Under  the  project  officer  is  a  user  group  with  repre¬ 
sentatives  from  the  affected  staff  sections  and  one  or  more 
senior  technicians  —  which  ones  to  be  determined  by  the  appli¬ 
cation  being  defined.  Also  under  the  project  officer  is  a  Tech¬ 
nical  Group  including  the  technicians  and  representatives  from 
the  immediately  affected  staff  sections  --  which  ones  to  be 
determined  again  by  the  application  under  development.  The 
project  officer  must,  for  such  an  organization  to  be  effective, 
be  of  the  change-agent  type.  The  more  of  these  that  can  be 
identified  and  assigned  throughout  this  organization,  the  more 
rapidly  the  users  and  technicians  will  be  able  to  function  to¬ 
gether  effectively.  It  is  most  important  to  impress  them  with 
the  idea  that  their  mission  is  to  make  data  processing  technology 
useful  to  the  user  and  to  translate  military  requirements  into 
terms  the  technicians  can  understand.  Their  function  is  not  to 
become  system  salesmen. 

2.3  BASIC  GUIDELINES 


Successful  introduction  and  implementation  of  automated 
support  for  the  tactical  C*  system  is  based  on  the  application  of 
the  following  operational  principles: 

•  You  must  first  develop  a  system  concept. 

Just  as  a  successful  OPLAN  must  be  based  on  a 
carefully  selected,  clearly  enunciated  concept  of 
operations,  so  also  must  the  initial  implementation 
(and  subsequent  iterations)  of  automated  support  be 
tied  to  a  carefully  developed  concept  of  "informa¬ 
tion  operations"  when  the  Cl  system  is  supported 
with  automation. 

i  Commander  and  senior  staff  must  be  personally 
involved .  ~ 

No  change  to  the  Cz  system  —  and  the  introduction 
of  automation  will  introduce  some  profound  changes 
—  can  succeed  without  the  personal  involvement  of 
the  commander  and  jSenior  affected  staff  officers. 
After  all,  the  C^  system  exists  solely  for  the 
purpose  of  facilitating  the  making  of  tactical 
decisions  by  the  commander  and  senior  staff?  it  is 
their  system?  it  must  help  them  solve  their  prob- 
lems  in  their  unique  mode  of  decision  making. 
Unless  they  have  helped  develop  the  concept  and 
have  interest  in  its  implementation,  the  concept 
will  fail. 


IF  YOU  FAIL  TO  APPLY  THIS  PRINCIPLE,  YOU  MAY  AS 
WELL  ABORT  THE  EFFORT  NOW l 


>  Automation  must  be  integrated  into  total  system 
operation . 

There  is  much  more  to  the  introduction  of  automated 
support  than  merely  making  data  processing  gear 
available  to  the  staff.  Even  though  the  initial 
concept  may  be  limited  to  providing  support  for 
only  one  or  two  applications,  the  impact  on  the 
remainder  of  the  system  of  providing  that  limited 
support  must  be  assessed  if  the  potential  benefit 
is  to  be  in  any  way  exploited. 

•  Implementation  must  be  phased  in  gradually. 

The  introduction  of  automation  is  frequently  a 
classic  case  of  the  "eyes  being  bigger  than  the 
stomach."  Even  though  any  degree  of  automation 
requires  a  total  system  evaluation,  the  concept 
implementation  must  be  carefully  phased  so  that  the 
effort  does  not  exceed  man,  machine,  or  system 

capabilities  at  any  stage.  It  is  far  better  to 
have  potential  customers  waiting  for  their  favorite 
application  than  to  promise  something  you  can't 
deliver. 

•  System  development  must  be  an  evolutionary  process. 
Phased  implementation ,  in  turn,  requires  evolu- 
tionary  development;  establish  initial  goals, 
develop  the  needed  support,  try  it  out,  improve  it 
and  then  go  on  to  new  goal^.  It  should  be  noted 
that  the  development  of  a  CZ  system  will  never  be 
finished  or  completed. 

The  application  of  the  above  principles  to  the  tasks  inherent  in 
the  development  is  discussed  in  greater  detail  in  the  following 
paragraphs . 

2.4  IMPLEMENTING  SEQUENCE 

In  addition  to  the  Basic  Guidelines  enunciated  above, 
one  needs  to  follow  a  logical  sequence  of  stages  and  tasks  in 
implementing  the  effort.  Such  a  sequence  is  provided  by  Figure 
2-2  which  is  sort  of  a  roadmap.  It  lists  five  stages  which  should 
be  followed  for  each  incremental  application  of  automation  to  the 
CZ  system  and  indicates  who  has  the  lead  for  each  stage.  Then  it 
shows  tasks  required  in  each  stage  and  suggests  techniques  appro¬ 
priate  for  each.  The  remaining  paragraphs  of  this  section  discuss 
the  application  of  the  basic  guidelines  to  this  framework  and 
describe  some  applicable  techniques. 

2.5  COMMANDER  (USER)  INVOLVEMENT 

Figure  2-3  shows  the  suggested  involvement  by  the  com¬ 
mander,  Chief  of  Staff  and  Senior  Staff  in  the  task  sequence 
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TECHNIQUES 


Figure  2-2.  ROAD  MAP  FOR  ORGANIZING  EFFORT 
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Figure  2-3.  SENIOR  USER  INVOLVEMENT  DURING  DEVELOPMENT 
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portrayed  in  Figure  2-2.  It  indicates  the  nature  of  each  contact 
and  its  purpose.  The  contacts  with  senior  users  indicated  in  the 
figure  are  the  absolute  minimum;  other  progress  briefings  are 
clearly  indicated  for  some  of  the  longer  stages  such  as  concept 
development  and  software/system  development. 

The  goals,  i.e.,  the  output  products,  selected  in  con¬ 
cept  development  for  improvement  through  computer  support  must  be 
of  major  concern  to  the  commander  and  principal  staff.  Since  the 
tactical  C2  system  exists  to  support  their  decision  making,  they 
are  the  principal  users  and,  hence,  very  properly  make  the  final 
decisions  as  to  how  that  system  will  function  and  be  organized. 
It  is,  therefore,  of  the  utmost  importance  that  they  select  the 
initial  package  of  staff  outputs,  from  now  on  called  applica¬ 
tions,  to  be  assisted  through  automation.  Furthermore,  it  is  to 
the  commander  and  senior  staff  that  the  improvements  achieved 
must  be  demonstrated.  Therefore,  they  must  also  be  involved  in 
the  selection  of  measures  used  to  demonstrate  that  improvement. 
It  is  not  sufficient  to  have  a  top-down  approach  to  system  de¬ 
sign;  there  must  also  be  top-down  involvement  in  its  implementa¬ 
tion  or  the  effort  will  surely  fail. 

The  initial  briefing  is  certainly  the  most  important 
since  it  will  set  the  stage  for  the  entire  development.  It 
should  take  place  as  soon  as  possible  after  receipt  of  the  mis¬ 
sion.  The  project  officer(s)  should  do  enough  spadework  prior  to 
the  briefing  so  that  he  can  discuss  the  nature  of  the  effort 
required,  the  major  capabilities  and  limitations  of  automation  in 
the  TOC,  and  some  candidate  applications  and  goals.  He  should 
indicate  the  nature  of  and  estimate  the  size  of  the  resources 
required  and  outline  the  proposed  organization  of  the  effort. 
Many  of  the  illustrations  and  tables  in  this  manual  can  be 
adapted  as  slides  for  this  briefing. 

Almost  as  important  as  the  initial  briefing  is  the 
"hands  on"  experience  during  the  initial  operator  training  and 
the  later  demonstrations  and  trials.  If  the  initial  application 
to  be  implemented  is  to  demonstrate  improvements  achieved  through 
automation,  several  of  this  senior  group  (Commander,  Chief  of 
Staff,  and  senior  staff  officers)  must  be  involved  at  the  termi¬ 
nals  .  There  is  no  better  or  faster  way  to  gain  an  appreciation 
of  the  potential  for  improvement.  The  remainder  of  the  briefings 
are  decision  briefings  at  key  points  in  the  development  cycle. 
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CONCEPT  DEVELOPMENT 


CONCEPT  DEVELOPMENT 

■ 

Define  Computer  Aided  System  Goals 

2. 

Analyze  Required  Information  Processes 

TASKS 

3. 

Size  &  Phase  Proposed  Applications 

I 

Develop  Total  System  Impact  (SOP) 

5. 

Prioritize  Applications 

A  detailed  concept  must  includes 

•  A  clear  definition  of  what  is  to  be  accomplished 
through  computer  support  in  terms  of  measureable, 
demonstrated  improvement  of  some  intermediate  or 
final  output  product  of  the  commander  and  staff.  A 
proper  goal  might  be  the  improvement  of  the  SITMAP 
and  other  visible  displays  to  be  measured  by 
reduced  lag  time  between  event  and  perception, 
reduced  error  rates,  more  complete  representations, 
and  a  reduction  in  the  number  of  misperceptions. 
This  goal  is  attained  through  improved  processing 
of  incoming  messages,  particularly,  spot  reports 
and  SITREPS,  but  the  latter  is  not  the  measureable 
goal,  only  the  means  to  it. 

•  A  careful  analysis  of  the  processes  required  to 
produce  the  particular  staff  output(s)  product 
selected  above.  Normally,  this  will  be  some  por¬ 
tion,  or  all,  or  even  iteration  of  the  processes 
shown  in  Figure  2-4. 

•  Careful  selection  of  which  of  the  above  processes 
are  to  be  assisted  through  automation.  This  re¬ 
quires  a  tradeoff  between  the  capabilities  shown  in 
Table  3-1  and  the  constraints  inherent  in  your 
available  resources. 
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•  A  detailed  set  of  procedures  for  performing  both 
the  machine  and  human  processing  required  to 
produce  the  measureable  product.  This  will,  of 
course,  have  to  be  modified  as  the  development 
proceeds  and,  most  certainly,  as  a  result  of  the 
initial  trials.  It  is  important  to  note  that  this 
set  of  procedures  will  almost  certainly  be  diff¬ 
erent  from  the  procedures  used  in  all-manual 
processing . 

The  whole  notion  of  having  to  develop  a  formal  concept 
of  "information  operations"  is  somewhat  foreign  to  us;  after  all, 
we  have  been  organizing  and  training  staffs  (the  decision  nodes 
in  the  tactical  u  system)  for  years  without  prescribing  a  de¬ 
tailed  set  of  operational  procedures  for  carrying  out  the  neces¬ 
sary  information  processes.  Such  detailed  procedures  were  devel¬ 
oped  as  we  needed  them.  A  formal  SOP  was  usually  prepared  to 
cover  such  special  requirements  as  displacement,  enemy  attack  on 
the  CP,  nuclear  release,  chemical  attack,  and  vitally  needed 
reports,  but  the  routine  processing  took  care  of  itself. 

FM  101-5  describes  the  duties,  responsibilities,  and  functions  of 
commanders  and  staffs  and  describes  in  some  detail  what  has  to  be 
done.  Appropriate  TOEs  list  the  assets  authorized  to  perform 
these  tasks.  The  ARTEPS  provide  performance  standards  and,  hope¬ 
fully,  personnel  assigned  are  qualified  in  their  MOS. 

None  of  the  above  documents,  however,  provide  much 
guidance  on  how  to  carry  out  the  doctrinally  prescribed  tasks 
other  than  a  few  formats  for  the  major  staff  products  and  what 
can  be  inferred  from  MOS  specified  skills.  Staff  organization 
and  procedures  have  tended  to  follow  the  same  pattern  of  develop¬ 
ment  followed  by  other  free-form  groups  consisting  primarily  of 
human  components.  Such  groups  strive  to  structure  their  work 
environments  to  reduce  the  amount  of  stress  they  must  face  by 
directing  their  activities  toward  a  more  workable  and  predictive 
level  of  certainty  and  clarity.  Group  members,  interacting  over 
a  period  of  time,  will  develop  standard  work  patterns  in  which 
routine  and  precedent  play  a  relatively  large  part. 

This  somewhat  casual  approach  to  the  detailed  ordering 
of  the  information  processing  is  understandable  and  reasonably 
successful  when  "machine"  support  is  limited  to  voice  and  tele¬ 
type  communication,  typewriters,  manual  displays  and  files,  and 
possibly  a  Xerox  or  two.  In  such  a  manual  system  information 
processes  are  all  performed  by  human  beings  which  are  among  the 
most  highly  variable,  nonstandard  parts  from  which  a  system  can 
be  formed.  Furthermore,  humans  are  almost  infinitely  adaptable; 
whenever  one  or  more  members  of  the  team  change,  the  rest  adapt 
to  the  skills,  limitations  (and  prejudices)  of  the  replacements 
—  especially  of  the  senior  members.  As  a  result,  no  two  staffs 
process  information  in  exactly  the  same  way  nor  do  the  two  shifts 
of  the  same  staff  operate  in  an  identical  manner. 


The  advent  of  automated  support  changes  all  this.  Even 
though  software  can  be  made  somewhat  flexible  and  adaptive, 
still,  to  the  degree  that  information  processing  is  performed  by 
machine,  the  information  system  now  contains  "standard"  parts 
which  impose  a  degree  of  discipline  in  system  design  and  opera¬ 
tion  far  greater  than  was  required  when  it  was  populated  only  by 
people.  This  does  not  mean  that  automation  alone  can  drive  your 
systems  design.  Clearly  it  must  respond  to  the  commander's 
wishes  and  accommodate  the  real  world  situation.  However,  with¬ 
out  a  detailed  concept  of  just  how  the  information  processing  is 
to  be  improved  through  computer  support,  the  effort  will  floun¬ 
der;  very  little,  if  any,  improvement  will  result  and  many,  many 
resources  and  much  time  will  have  been  wasted. 

It  is  the  purpose  of  this  paragraph  to  show  how  such  a 
concept  may  be  developed.  Clearly,  the  ball  is  on  the  user  side 
of  the  house  for  the  tasks  in  this  phase  (Figure  2-2);  the  spade¬ 
work  can  be  accomplished  by  the  User  Group  and  approval  of  the 
Steering  Committee  must  be  obtained. 

2.6.1  Identifying  Applications 


There  are  a  number  of  ways  to  get  this  effort  off  the 
ground.  These  include  brainstorming  sessions,  questionnaires, 
and  the  Delphi  Method,  the  latter  being  one  of  the  means  which 
can  provide  a  consensus  if  you  stick  to  written  questionnaires. 
You  can  also  use  a  combination  of  these  means.  The  key  to  get¬ 
ting  users  to  submit  original  and  useful  suggestions,  regardless 
of  which  means  are  used  to  elicit  them,  is  to  stimulate  the  user 
by  providing  some  well  thought  out  "strawmen."  People  are  always 
more  willing  to  comment  on  proposals  made  by  someone  else  than 
they  are  to  initiate  original  suggestions  —  and  in  the  process 
of  commenting  they  will  frequently  be  stimulated  to  come  up  with 
some  new  ideas.  The  group  solicited  for  suggestions  must  include 
the  commander  and  senior  staff  as  well  as  other  members  of  the 
staff.  Although  the  suggestions  from  the  commander  and  senior 
staff  have,  ipso  facto,  priority,  the  lower  level  participants 
may  well  provide  valuable  insights  and  plug  gaps  in  the  submis¬ 
sions  of  their  seniors.  One  possible  sequence  (out  of  many 
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others  equally  good  depending  on  time  and  circumstance)  would  be 
to  use  a  questionnaire  to  elicit  comments  and  suggestions  on  a 
set  of  applications  you  have  provided  as  a  strawman.  Then,  after 
you  have  listed  a  modified  set  of  applications  based  on  the  ques¬ 
tionnaires  (anonymous,  of  course)  convene  a  brainstorming  session 
of  the  user  group  and  later  of  the  steering  committee  to  gain  a 
consensus,  or  follow  the  alternate  route  using  the  Delphi  Method 
to  gain  the  consensus. 

Bach  candidate  application  must  be  expressed  in  terms  of 
clearly  identified  products  of  the  TOC  that  are  to  be  improved 
through  automated  support.  These  could  be  products  produced  as 
outputs  from  the  TOC  (e.g.,  plans,  orders,  reports)  or  they  could 
be  internal  products  that  appear  at  major  internal  interfaces 
within  the  TOC  (e.g.,  estimates,  daily  briefing,  SITMAP) .  In 
addition  to  identifying  the  candidate  output  which  is  to  be  im¬ 
proved,  the  submission  must  specify  exactly  how  this  product  is 
to  improve.  If  possible  this  improvement  goal  should  be  ex¬ 
pressed  quantitatively: 

e  Reduce  staff  preparation  time  for  this  _  to  less 

than  30  minutes. 

e  Reduce  lag  time  between  input  message  and  to 

less  than  5  minutes. 

•  Reduce  discrepancies  between  friendly  input  loca¬ 

tions  and  displayed  locations  to  less  than  1%. 

If  it  is  not  possible  to  express  the  improvement  quantitatively, 
the  improvement  goal  must  be  described  in  sufficient  detail  so 
that  there  can  be  no  doubt  when  the  desired  level  of  improvement 
has  been  demonstrated. 

2.6.2  Applications  Analysis 


The  candidate  applications  must  now  be  analyzed  to 
determine: 


•  Which  of  the  processes  required  for  each  applica¬ 
tion  can  be  supported  by  automation 

•  The  probable  contribution  of  each  toward  the  appli¬ 
cation  goal 

•  The  probable  cost  in  time  and  dollars 
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A  suggested  way  to  initiate  this  analysis  is  to  develop  a  flow 
chart  of  the  functions,  processes,  and  data  bases  required  to 
produce  the  output(s)  identified  in  the  specific  applications. 
The  general  model  of  <;  group  processing  steps  shown  at  Figure 
2-4  provides  the  building  blocks  for  this  effort.  Do  this  ini¬ 
tially  to  show  how  these  outputs  are  produced  in  the  manual  mode. 
Be  sure  to  include  all  of  the  processing  needed  all  the  way  back 
to  the  data  stream,  both  in  and  out.  An  example  of  such  a  flow 
chart  is  provided  in  paragraph  3.9. 

Modify  the  above  flow  chart  to  reflect  how  you  visualize 
it  will  be  changed  when  supported  by  the  proposed  automation. 
This  will  be  an  iterative  procedure  as  you  examine  several  dif¬ 
ferent  candidate  processes  for  automation  and  recall  that  an 
automated  data  base  must  be  shown  separately  to  support  the  pro¬ 
cesses  you  intend  to  automate.  A  preliminary  estimate  of  the 
potential  payoff  to  be  gained  by  providing  automation  support  to 
the  various  processes  included  in  your  flow  charts  can  be  gained 
by  referring  to  Table  3-1.  This  table  lists  the  key  limitations 
and  capabilities  of  man  alone,  machine  alone,  and  man-machine 
together  for  the  performance  of  each  process.  When  you  have 
narrowed  your  configurations  down  to  the  few  that  show  the  most 
promise  toward  achievement  of  your  application  goals  you  have 
arrived  at  the  stage  where  you  need  to  get  some  solid  data  pro¬ 
cessing  expertise  from  senior  technicians.  They  can  provide 
quite  definitive  estimates  of  how  much  progress  toward  your  goal 
can  be  achieved  by  each  likely  configuration  of  automation  sup¬ 
ported  processes.  In  general,  it  will  be  necessary  to  identify  a 
separate  data  base  for  those  data  elements  that  are  going  to  be 
processed  by  machine.  The  major  change  from  the  manual  flow 
chart  is  the  identification  of  the  interfaces  which  will  become 
man-machine  terminals.  Remember  that  you  must  ultimately  provide 
for  every  data  element  needed  as  input  into  the  automated  data 
base  and  for  every  desired  output. 


I 


DECISION  FUNCTION 


2.6.3  Sizing  and  Phasing 


Your  senior  technician  will  also  be  able  to  give  you 
guidance  on  the  cost,  both  in  terms  of  time  and  effort  as  well  as 
money.  This  is  the  principle  reason  that  one  or  more  should  be 
included  in  both  the  User  Group  and  the  Steering  Committee. 
Another  factor  that  will  become  apparent  early  on  in  this  stage 
of  the  analysis  is  the  data  base  implication  of  automating  almost 
any  of  the  processes  or  of  assisting  a  man  in  carrying  out  any  of 
the  processes  by  means  of  automation.  A  digital  data  base  must 
be  established  for  every  such  process.  One  of  the  hidden  costs 
that  must  be  minimized  is  that  of  maintaining  dual  (manual  and 
automated)  data  bases  for  the  same  subject  matter. 

For  the  larger  applications  such  as  the  Commander's 
briefing  (see  paragraph  3.9  for  a  discussion  of  the  commander’s 
briefing  problem)  it  will  be  clear  that  the  ultimate  goal  cannot 
be  achieved  in  a  single  iteration.  Such  a  single  massive  leap 
into  automation  is  neither  practicable  nor  desirable.  Not  only 
would  it  exceed  currently  available  resources,  but,  even  more 
important,  it  would  require  a  period  of  time  to  plan,  design, 
develop,  and  implement  far  longer  than  available.  If  improvement 
of  the  operation  through  computer  support  cannot  be  demonstrated 
in  some  measureable  degree  during  the  current  tour  of  duty  of  the 
commander  and  senior  staff  the  effort  will  most  assuredly  have  to 
start  all  over  again  from  scratch  at  some  future  time.  This 
leads  us  to  the  fourth  basic  guideline;  the  effort  to  provide 
computer  support  must  be  phased.  This  means  not  so  much  curbing 
the  appetite  for  automation  as  breaking  it  into  chunks  of  manage¬ 
able  size.  Each  application  considered  should  lie  well  within 
your  resources  both  in  terms  of  dollars  and  available  technical 
expertise  and  it  must  also  be  doable  and  demonstrable  within  a 
reasonably  short  period  of  time.  The  initial  application  should 
also  be  selected  on  the  basis  that  it  is  a  logical  first  step 
toward  whatever  ultimate  goal  has  been  established  for  achieve¬ 
ment  through  computer  support. 

Defining  and  phasing  the  successive  applications  which 
will  lead  you  to  the  ultimate  goal  that  has  been  established 
requires  that  you  start  with  that  goal  and  then  develop  an  appro- 
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priate  phasing  strategy  by  which  that  goal  can  be  reached.  For 
example#  if  the  ultimate  goal  is  a  dispersed  command  post#  you 
could  follow  the  general  strategy  which  is  sketched  in  paragraph 
3.9#  and  is  essentially  based  on  providing  automated  support  for 
a  series  of  staff  products#  viz.#  commander's  briefing  (incre¬ 
mentally)#  commander's  and  staff  estimates,  staff  data  bases 
(finally  integrated  into  a  common,  distributed  data  base);  pre¬ 
paration  of  OPLAN/ORDERS  and  reports;  and  finally  input  and 
output  processing  (frequently  called  "electronic  mail").  Another 
strategy  might  be  the  successive  physical  separation  of  TOC  com¬ 
ponents  beginning  with  automation  of  selected  traffic  between  TOC 
at  MAIN  and  TAC.  The  incremental  applications  should  again  be 
tied  to  clearly  identified  staff  products.  Whatever  strategy  is 
selected  —  this  will  depend  largely  on  the  commander's  guidance 
—  there  are  some  basic  system  design  rules  which  should  be 
observed  in  implementing  the  strategy: 

1  •  Each  successive  application  (not  just  the  %jrst)  must 
demonstrably  improve  the  performance  of  the  system. 

In  general#  this  means  that  the  application  must  be  tied  to  one 
or  more  staff  products  and  specified  quantitative  improvements  in 
their  production. 

2 .  In  planning  successive  applications#  each  should  exploit 
the  capabilities  already  provided  by  its  predecessors. 

It  cannot  be  repeated  too  often  that  the  incremental  introduction 
of  automated  support  means  the  incremental  transition  from  all- 
manually  created  to  automated  data  bases.  The  latter  should#  of 
course#  be  common  (accessible  by  anyone  who  needs  the  informa¬ 
tion)  and  distributed  (for  survival).  Successive  applications 
must  provide  for  an  orderly  transition  from  one  to  the  other  with 
minimal  duplication  of  labor  at  each  intermediate  stage. 


3 .  In  planning  successive  phases  keep  in  mind  that  commo 

capacity  is  not  a  "free  good";  USE  COMMO  CHANNELS  ONLY 
FOR  THE  TRANSMISSION  OF  DYNAMIC  INFORMATION  --  never 
for  the  transmission  of  static  information  which  should 
be  stored  locally. 

In  plainer  english,  do  not  use  the  commo  system  to  transmit  com¬ 
plete  formats#  displays#  or  charts.  Instead,  transmit  only  that 
information  required  to  keep  the  data  elements  in  the  data  base 
current.  Ideally#  the  user  should  be  able  to  display  the  data  he 
needs  in  a  format  of  his  choice;  the  system  retrieves  the  updated 
data  elements  needed  to  complete  it.  As  an  obvious  example, 
transmit  only  the  data  on  the  overlay  --  not  the  entire  map 
underneath  it. 


4. 


A  top-down  approach  to  providing  automated  support, 
i.e.,  beginning  with  products  that  require  the  decision 
processes  (Figure  2-4) ,  then  the  pre-  and  post-decision" 


processes ,  and  final! 
will  lead  to  a  more  e 


Ly  the  input  and  output  processesT 
fficient  system  designT 


Numerous  visits  to  units  participating  in  the  TACIP  program  have 
emphasized  this  principle.  Defining  the  commander’s  needs  first 
makes  the  determination  of  what  data  are  needed,  where  to  get 
them,  and  how  to  sort,  correlate,  and  aggregate  them  for  presen¬ 
tation  a  relatively  straightforward  task.  Starting  at  the  bottom 
with  "electronic  mail"  tends  to  include  every  possibility  at  the 
lower  levels  and  then  ignore  those  not  needed  as  the  system  is 
developed  upward. 


The  above  discussion  has  concentrated  on  the  question  of 
defining  a  logical  progression  of  applications  aimed  at  the 
achievement  of  a  larger  goal.  The  discussion  at  paragraph  2.6.5 
provides  additional  information  on  sizing  and  prioritizing 
applications . 


For  such  larger  applications  it  will  be  necessary  to 
break  the  job  down  into  a  series  of  smaller  tasks.  This  really 
amounts  to  redefining  the  application  into  a  series  of  steps  with 
intermediate  goals  for  each.  This,  in  turn,  requires  drafting  a 
series  of  flow  charts,  one  for  each  product  that  is  to  be  pro¬ 
duced  with  automation  assistance.  Note  which  is  the  highest 
level  function  that  is  involved  in  preparing  the  product,  i.e., 
does  it  involve  commander  decision  making,  the  highest  level  of 
info  processing  and  decision  making;  mid-level  (staff)  decision 
making/info  processing;  or  only  lower  level  message  input/outout 
processing?  Figures  2-5,  2-6,  and  2-7  have  been  designed  to 
assist  you  in  drafting  the  flow  charts  after  you  have  determined 
the  function  level(s)  involved.  Figure  2-5  shows  partial  auto¬ 
mation  to  assist  the  commander's  decision  function.  It  indicates 
that  the  information  flow  between  the  commander  and  the  staff  is 
partly  through  an  automated  data  base  and  partly  manual.  For 
example,  if  only  the  staff  estimates  and  the  commander's  guidance 
were  to  flow  between  commander  and  staff  via  automated  terminals, 


any  additional  decision  processing  by  the  commander  (additional 
alternatives,  answering  other  "what  if"  questions)  would  have  to 
flow  over  the  manual  interfaces  indicated.  Figure  2-6  similarly 
presents  the  middle  or  staff  processing  level  of  the  C4  Info 
Processing/Decision  Making  System.  Figure  2-7  similarly  presents 
the  lower  layer,  i.e.,  the  input/output  and  pre-/post-decision 
processes  which  might  be  partially  automated  by  means  of  "elec¬ 
tronic  mail."  Your  flow  charts  are  not  finished  until  you  have 
identified  every  information  transfer  across  each  automated  and 
manual  interface  needed  for  the  product  under  consideration.  A 
technique  for  further  identifying  the  needed  interfaces  and 
displaying  them  is  disucssed  in  paragraph  2.7  below.  A  logical 
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MANUAL  OPERATION 


AUTOMATED  OPERATION 


MANUAL  INTERFACE 
(BRIEFINGS.  SITMAPS,  CHARTS) 


AUTOMATED  INTERFACE 
(TERMINAL) 


MANUAL  DATA  BASE 
(SITMAPS,  TOTE 
BOARDS.  FILES) 


AUTOMATED 
DATA  BASE 


MANUAL  INTERFACE 
(POSTING  MAPS  &  DISPLAYS; 
PREPARING  BRIEFING  NOTES 
AND/OR  REPORTS) 


AUTOMATED  INTERFACE 
(TERMINAL) 


STAFF  SECTION  (MID  LEVEL)  DECISION  1 

FUNCTION 

EVAL/COORD 

GEN  ALTV  S 

/  \  / 

'  \ 

INTER/VAUD  PROJ/EXT 

DECIDE 

STAFF  SECTION  (MID  LEVEL)  DECISION 
FUNCTION 


EVAL/COORD 


GEN  ALTV'S 


/  \  /  \ 


INTER/VALID  PROJ/EXT 


DECIDE 


CHARACTERISTICS: 

•  MANUAL  OPERATION  REQUIRES  COLOCATION 
OF  CMDR.  DATA  BASE.  &  STAFF 

•  HENCE.  CMDR'S  DECISION  FUNCTION 
MUST  BE  SCHEDULED  (DAILY  BRIEFINGS) 


CHARACTERISTICS: 

•  LENDS  ITSELF  TO  DISPERSED  LOCATION 

•  HENCE,  CMDR'S  DECISION  FUNCTION  CAN 
BE  INVOKED  AS  REQUIRED  (CONTINUING 
ESTIMATE) 


Figure  2-6.  PARTIAL  AUTOMATION  -  CMDR'S  DECISION  FUNCTION 
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MANUAL  OPERATION 


AUTOMATED  OPERATION 


STAFF  SECTION  (MID-LEVEL)  DECISION 
FUNCTION 


EVAL/ COORD  GEN  ALTV’S 

/  \  /  \ 

INTER/VAL  PROJ/EXT  DECIDE 

MANUAL  INTERFACE 
(POST  &  ACCESS  SITMAPS, 
TOTE  BOARDS.  FILES,  &  MEMORY) 


♦ 

MANUAL  PERCEIVED 
DATA  BASE 
(SITMAPS,  TOTE 
BOARDS,  FILES) 

i  r 

MANUAL  INTERFACES 
(POST  &  ACCESS  SITMAPS. 
TOTE  BOARDS.  FILES,  &  MEMORY) 


STAFF  SECTION  (MID-LEVEL)  DECISION 
FUNCTION 


EVAL/  COORD  GEN  ALTV'S 

/  W  \ 

INTER/VAL  PROJ/EXT  DECIDE 

- I - 


AUTOMATED  INTERFACE 
(TERMINAL) 


i 


AUTOMATED 
PERCEIVED 
DATA  BASE 


I 


AUTOMATED  INTERFACES 
(TERMINAL) 


i 


PRE-DECISION 

POST-DECISION 

FUNCTION 

FUNCTION 

AGGREGATE/ORG 

ASSOCIATE 

ASSOCIATE 

REAGGREGATE 

SORT 

SORT 

J 


▼ 


Figure  2-6.  PARTIAL  AUTOMATION  -  STAFF  DECISION  AND 
PRE-/POST-  DECISION  FUNCTIONS 
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MANUAL  OPERATION 


AUTOMATED  OPERATION 


EXTERNAL  INFORMATION  STREAM 


EXTERNAL  INFORMATION  STREAM 


Figure  2-7.  PARTIAL  AUTOMATION  -  PR E-/ POST-  DECISION  AND 
INPUT/OUTPUT  FUNCTIONS 
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development  sequence  can  now  be  determined  by  grouping  together 
into  single  applications  those  products  which  share  the  largest 
number  of  automated  data  transfers.  Applications  can,  in  turn, 
be  sequenced  by  adding  them  in  the  sequence  which  provides  assis¬ 
tance  to  the  largest  number  of  high  priority  products  with  the 
smallest  addition  of  automated  data  transfers. 

Several  things  will  be  noted  about  flow  charts  con¬ 
structed  in  this  fashion: 


e  All  flow  charts  for  products  that  involve  the 
same  functions  will  be  essentially  identical;  the 
differences  will  lie  in  the  needed  data  exchanges. 

#  As  you  automate  more  and  more  products  in  one  of 
the  large,  phased  applications,  the  data  flow  will 
tend  to  flow  more  and  more  over  the  automated 

channels  and  the  manual  exchanges  will  tend  to 
disappear. 

e  Although  shown  as  separate  data  bases  for  each  of 
the  function  levels,  this  is  a  purely  functional 
representation.  The  automated  data  bases  at  each 
level  need  not  be  physically  separated,  nor 
physically  collocated  with  the  information 

functions  and  processes  they  support  (as  do  the 
manual  data  bases)  . 

2.6.4  Total  System  Impact 

How  Will  ADP  Application  Affect  SOP? 

Do  Redundant  Data  Bases  Increase  Workload? 

What  Effect  Does  Application  Have  On  Workload  Schedule? 
How  Does  Application  Affect  Task  Assignment? 

How  Does  Application  Affect  TOC  Layout? 

How  Does  Application  Facilitate  TOC  Dispersion? 

How  Does  Application  Affect  Required  Communications? 

The  flow  charts  developed  as  described  above  are  also 
very  useful  for  assessing  total  system  impact.  To  be  complete 
they  should,  of  course,  include  that  part  of  the  operation  that 
remains  manual  as  well  as  that  which  is  proposed  for  automation. 
One  needs  now  to  develop  a  detailed  SOP  for  system  operation  in 
the  computer  assisted  mode  in  order  to  determine  how  automation 
affects  the  entire  operation.  In  some  cases  the  proposed  auto¬ 
mation  could  add  to  the  manual  workload,  e.g.,  by  requiring 
personnel  to  maintain  duplicate  data  bases,  or  instead  of  smooth¬ 
ing  out  workload  it  could  cause  it  to  pile  up  at  critical  nodes. 
Careful  study  of  the  flow  chart  can  disclose  such  potential  pit- 
falls  before  they  arise  in  actual  practice.  What  you  are  doing 
here  is  assessing  system  costs  that  are  outside  the  actual 
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automated  part  of  the  revised  system. 

Whenever  automation  is  used  to  process  information  con¬ 
tinuously  rather  than  on  a  scheduled  basis  (e.g.,  a  continuously 
updated  appreciation  of  the  situation  from  spot  reports  instead 
of  periodic  summary  reports)  there  will  be  a  tendency  to  smooth 
out  peaks  in  the  loading.  A  dramatic  example  of  such  a  shift  in 
information  loading  is  discussed  in  paragraph  3.9.1. 

This  step  will  also  help  you  identify  changes  in  work¬ 
load  and  needed  changes  in  task  assignment  and  layout  of  the  TOC. 
It  will  also  help  avoid  the  fiasco  of  designing  a  system  more 
difficult  to  operate  than  the  manual  mode. 

Finally,  note  any  possible  changes  in  location  of  TOC 
elements  that  would  be  facilitated  by  the  automation  introduced 
by  the  initial  (later)  applications  --  especially  changes  leading 
to  the  desirable  goal  of  CP  dispersion. 

As  part  of  this  last  step  you  must,  of  course,  also  make 
an  estimate  of  the  changes  needed  in  your  communication  support 
to  permit  such  dispersion. 

Carrying  out  these  steps  will  go  a  long  way  toward  in¬ 
suring  a  smooth  transition  to  computer  supporter  operations  when 
you  are  ready  to  bring  your  application  on  line  and  will  help 
avoid  unpleasant  surprises  because  of  some  factor  that  has  been 
overlooked.  It  is  recognized  that  you  may  not  be  able  to  iden¬ 
tify  all  problems  at  this  stage  of  the  development  process. 
However,  major  problems  that  could  affect  system  operation  and/or 
user  acceptance  should  be  identified  at  this  time. 

2.6.5  Prioritization 


The  last  step  in  concept  analysis  and  its  final  product 
is  putting  the  candidate  applications  into  the  sequence  in  which 
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they  should  be  implemented.  Now,  if  your  individual  applications 
are  all  phases  of  a  single  larger  application  and  have  been  de¬ 
veloped  as  indicated  in  paragraph  2.6.3  above,  you  have  already 
accomplished  this  prioritization.  If,  however,  they  are  separate 
applications  small  enough  not  to  require  phasing,  you  need  to 
consider  the  question  of  the  sequence  in  which  they  should  be  im¬ 
plemented.  To  do  this  you  need  estimates  of  the  payoff  of  each 
and  their  relative  cost.  By  this  time,  you  should  already  have  a 
consensus  of  the  Steering  Committee  as  to  their  ranking  of  the 
payoffs  expected  from  each  of  the  candidate  applications.  You 
must  now  also  estimate  the  relative  cost.  The  costing  of  diverse 
applications,  both  in  terms  of  dollars  and  time,  is  not  as 
straightforward  as  it  might  appear.  This  difficulty  arises  from 
the  inevitable  overlap  in  both  hardware  and  software.  The  same 
hardware  can  serve  more  than  one  application  and,  frequently,  the 
same  package  of  software  is  required  for  more  than  one.  This 
means  that,  after  the  initial  application  has  been  implemented, 
there  are  significant  sunk  costs  which  can  reduce  the  total 
acquisition  cost  of  later  increments.  Thus,  the  incremental  cost 
of  adding  any  single  application  is  a  function  of  what  has  been 
acquired  for  applications  already  implemented.  This  will  be  a 
major  determinant  of  a  logical  sequence  for  the  phased 
implementation. 

A  way  to  approximate  these  costs  has  already  been  laid 
out  in  the  discussion  in  paragraph  2.6.3  above.  Instead  of  going 
back  to  the  actual  hardware  and  software  costs,  use  the  number  of 
information  transfers  required  for  the  products  included  in  each 
application  as  a  surrogate  for  actual  costs.  That  sequence  of 
applications  which  adds  the  smallest  number  of  transfers  for  each 
incremental  application  will  be  the  easiest  to  live  with  from  a 
costing  point  of  view,  provided  you  also  pay  attention  to  the 
design  rules  stated  in  paragraph  2.6.3  above.  If  the  sequence 
determined  in  this  way  differs  substantially  from  the  sequence  of 
"druthers"  arrived  at  by  the  Steering  Committee,  you  need  to  go 
back  to  them  and  make  a  trade-off  in  much  the  same  way  as  you 
select  a  course  of  action  in  making  a  staff  estimate,  that  is  by 
comparing  the  advantages  (payoffs)  vs  the  disadvantages  (costs). 
Above  all,  do  not  violate  the  cardinal  rule:  DO  NOT  SELECT  AN 
INITIAL  INCREMENT  WHICH  CANNOT  BE  DEMONSTRATED  PRIOR  TO  ROTATION 
OF  THE  COMMANDER  AND/OR  AFFECTED  SENIOR  STAFF. 

2.7  REQUIREMENTS  DEFINITION 

During  this  step  in  the  development  the  initiative  must 
remain  with  the  users,  but  with  an  increasing  amount  of  expert 
guidance  and  information  being  provided  by  the  senior  techni¬ 
cians.  It  is  at  this  stage  that  the  change  agent  becomes  of 
paramount  importance  in  facilitating  effective  communication 
between  them.  In  fact  he  is  probably  best  qualified  to  employ 
the  suggested  technique.  This  technique  which  will  assist  the 
user  in  formulating  his  requirements  in  a  manner  understandable 


to  the  technician  and  which  will  insure  complete  consideration  of 
all  the  requirements  is  a  technique  adapted  from  the  technicians 
themselves.  It  is  used  by  systems  analysts  in  designing  auto¬ 
mated  system  architecture,  but  is  equally  useful  to  you  in  your 
capacity  as, the  total  (man/machine)  system  designer.  It  is 
called  the  Nz  chart.  In  a  sense  it  is  the  complement  to  the  flow 
charts  with  which  you  are  already  familiar.  Flow  charts  are 
built  up  of  components:  functions  and  data  bases;  arrows  con¬ 
necting  these  show  the  information  flow  between  them.  Hence  a 
flow  chart  tends  to  emphasize  functions  and  data  bases.  The  Nz 
chart,  as  you  will  see,  emphasizes  the  interfaces  (information 
transfers)  between  functions  and  data  bases;  the  latter  simply 
serve  as  pegs  on  which  to  hang  the  interfaces. 

2 

The  N  chart  is  one  of  those  notions  which  is  very 
simple  but  hard  to  describe  without  sounding  complex.  You  don't 
have  to  draw  very  many  flow  charts  before  you  discover  that 
placement  of  the  components  (function  and  data  base  boxes  in  our 
case)  is  critical  if  you  want  to  avoid  confusion  and  crossovers 
in  drawing  in  the  interface  arrows.  This  is  especially  true  if 
there  are  many  such  interconnections.  If,  however,  we  draw  the 
function  and  data  base  boxes  along  the  diagonal  of  a  large 
square,  then  every  other  small  square  off  the  diagonal  represents 
a  potential  interface  between  the  function/data  base  boxes. 


If  the  diagonal  runs  from  left  to  right  downward,  the  small 
squares  above  and  to  the  right  of  the  diagonal  represent  poten¬ 
tial  interface  transfers  from  an  upper  diagonal  square  to  a  lower 
one,  and  vice  versa  for  the  off-diagonal  squares  to  the  left  and 
below  the  diagonal.  Thus,  there  is  an  off-diagonal  small  square 
for  every  possible  interface  between  function/data  base  boxes  on 
the  diagonal. 


This  is  easier  to  understand  if  we  use  a  concrete  exam¬ 
ple.  Pigure  2-7  is  the  Nz  chart  corresponding  to  the  flow  chart 
of  the  operation  section's  processing  contribution  to  the  com¬ 
mander's  briefing  shown  at  Pigure  3-7.  The  latter  shows  nine 
major  components  to  be  considered  for  the  commander's  briefing, 
so  Pigure  2-7  shows  a  9  X  9  matrix  with  the  function/data  base 
boxes  drawn  as  solid  squares  along  the  diagonal.  All  the  other 
boxes  in  the  matrix  are  outlined  by  dotted  lines  and  represent 
all  of  the  possible  interfaces  between  the  nine  major  components. 
There  are  9X9*  81  -  9*  72  such  potential  interfaces. 
Granted,  ji ot  all  of  these  will  actually  exist,  but  the  advantage 
of  the  n  chart  is  that  it  reminds  you  that  they  can  and  makes 
you  justify  every  empty  interface  box  where  no  interface  occurs. 
Where  an  interface  between  components  actually  occurs  a  circle 
has  been  entered  into  the  dotted  square  and  the  direction  of 
information  flow  is  indicated  by  an  arrow.  The  circle  is  entered 
in  the  same  row  as  the  component  originating  the  information  flow 
and  in  the  same  column  as  the  component  to  which  that  flow  is 
routed .  Therefore,  the  flow  is  to  the  right  and  down  for  compo- 
nents  to  the  right  and  down  along  the  diagonal;  to  the  left  and 
up  for  components  above  and  to  the  left  of  the  originating  compo¬ 
nent.  If  there  are  more  than  one  interface  indicated  along  any 
path  between  two  components  only  the  interface  at  the  correspond¬ 
ing  row  and  column  pertains.  Other  interfaces  along  that  path 
pertain  to  other  pairs  of  components.  The  same  names  have  been 
entered  in  the  diagonal  component  boxes  as  are  used  in  Figure 
3-7.  The  interface  entries  have  been  numbered  and  the  letter 
used  to  identify  the  interfaces  in  Pigure  3-7  has  also  been 
entered  near  the  bottom  of  each  circle  in  the  interface  boxes. 
Note  that  the  N2  chart  has  reminded  us  of  four  interfaces  which 
are  ignored  in  Pigure  3-7  so  that  four  circles  (3,  4,  5,  and  17) 
contain  no  letters.  These  represent  the  distinct  possibility 
that  pre-  and  post-processing  may  need  to  retrieve  previously 
filed  whole  messages  from  the  raw  data  base. 

To  continue  the  example,  note  that  the  flow  shown  in 
Figure  3-7  represents  Case  1  in  which  the  automated  briefing  data 
base  (labeled  BRIEFING  SOFTWARE  in  Pigure  2-7)  provides  the  com¬ 
mander  only  selected  predecision  processed  information  and  infor¬ 
mation  subjected  to  the  staff  decision  processes.  It  does  not 
assist  his  own  decision  making  by  allowing  him  to  repeat  or 
expand  staff  decision  processing  by  asking  "what  if”  questions  of 
the  BRIEFING  SOPTWARE .  Only  four  man/machine  interfaces  are 
shown  on  the  chart  (11,  13,  14,  and  16)  and  these  have  been 
marked  with  an  asterisk.  These  are,  of  course,  functional  desig¬ 
nations;  11  and  13  would  be  multiple  termin'''1  for  the  several 
staff  sections, 

2 

Table  2-1  can  now  be  developed  from  the  N  chart.  It 
describes  each  of  the  major  components  and  then  describes  the 
nature  of  every  information  exchange,  i.e.,  the  inputs  to  the 
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TOC,  the  numbered  interfaces,  and  the  TOC  outputs.  Since  all  but 
four  of  the  numbered  interfaces  represent  manual  data  exchanges, 
these  descriptions  are  in  very  general  terms.  In  this  connection 
the  term  "processed  information"  is  shorthand  for  the  information 
produced  by  the  pre-  and  post-decision  functions  and  "manipulated 
information"  is  shorthand  for  the  output  of  the  decision  pro¬ 
cesses.  The  latter  is  distinguished  by  the  fact  that  the  deci¬ 
sion  processes  contain  information  that  was  not  contained  in  the 
incoming  message  stream  (hypotheses,  interpretations,  extrapola¬ 
tions,  etc.).  It  is  when  we  come  to  the  man-machine  interface 
descriptions  that  requirements  definition  really  begins.  The 
power  of  the  n  techniques  springs  from  the  fact  that,  once  the 
inputs  and  outputs  to  the  automated  portion  of  the  system  have 
been  adequately  described,  the  technician  can  (with  the  operator- 
user's  help)  organize  the  needed  data  base  and  define  the  algo¬ 
rithms  needed  to  convert  input  into  output.  For  the  present 
example  this  conversion  is  fairly  simple,  although  outputs  may 
well  be  in  different  format  from  inputs  --  or  even  provide  a 
capability  to  construct  new  formats  from  scratch. 

The  descriptions  of  the  four  automated  interfaces  3hown 
in  Table  2-1  are  only  the  beginning.  These  must  now  be  expanded 
to  include  every  element  of  data  to  be  transferable  from  staff  to 
commander  and  return  through  the  automated  terminals  and  every 
format  to  be  employed.  If  self-formatting  is  to  be  available, 
the  range  of  such  formatting  must  be  agreed  upon.  You  will  note 
that  Interfaces  15  and  12  provide  the  loop  from  commander  to 
staff  around  the  automated  system.  Since  you  cannot  and  do  not 
desire  to  stop  the  commander  from  asking  questions  he  cannot  get 
answered  through  the  automated  terminal,  it  is  this  route  that 
will  be  taken  to  get  such  information  by  voice  communications. 
In  deciding  what  information  to  transmit  through  the  terminal, 
you  are  making  a  trade-off  between  these  two  means  of  communica¬ 
tion,  and  you  are  adding  to  the  workload  involved  in  STAFF 
DECISION  by  requiring  the  staff  to  maintain  two  data  bases  —  as 
was  pointed  out  in  Section  2.6.  You  will  also  note  that  this 
loop  provides  the  back-up  in  case  the  automated  system  goes  down 
--  it  represents  the  original  manual  way  of  conducting  the 
briefing . 


Using  this  technique  the  user  and  technician  working 
together  can  develop  a  statement  that  both  understand  and  that 
avoids  many  of  the  gaps  that  all  too  frequently  plague  require¬ 
ments  drafted  without  dual  participation. 

2.8  INITIAL  DEVELOPMENT 

As  you  move  into  the  development  phase  of  the  initial 
implementation  the  ball  is  definitely  in  the  technicians'  court. 
It  is  they  who  must  now  assume  primary  responsibility  for  adher¬ 
ing  to  the  schedule  that  should  have  teen  established  as  part  of 
the  initial  concept  development.  They  should  also  have  planned 
for  the  arrival  of  the  necessary  hardware  needed  to  initiate 
development.  This  does  not  mean  that  the  user  can  sit  on  his 
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TABLE  2-1.  FUNCTION,  MANUAL  DATA  BASE,  AND  INTERFACE 
DESCRIPTIONS  FOR  THE  COMMANDER'S  BRIEFING 

FUNCTIONAL  AND  MANUAL  DATA  BASE  DESCRIPTIONS 
INPUT 

•  Receives,  verifies,  and  tags  incoming  messages 

•  Enters  messages  In  RAW  DATA  BASE 

•  Passes  messages  to  PRE-DECISION 

RAW  DATA  BASE  (MANUAL) 

•  Stores  messages  In  retrievable  form 

•  Retrieves  and  passes  selected  messages  to  PRE-POST-DECISION 
PRE-DECISION  PROCESSING 

•  Sorts,  associates,  and  aggregates/organizes  information 

•  Files  processed  information  In  PROCcSSED  DATA  BASE  (manual) 

•  Queries  RAW  DATA  BASE  for  selected  messages 

PROCESSED  DATA  BASE  (MANUAL) 

•  Stores  processed  information  in  retrievable  form 

•  Provides  information  to  PRE-POST-DECISION 

•  Stores  manipulated  Information  from  STAFF  DECISION 

t  Provides  processed  and  manipulated  Information  to  STAFF  DECISION 

STAFF  DECISION 

o  Retrieves  processed  and  manipulated  data  from  PROCESSED  DATA  BASE 
t  Files  manipulated  data  In  PROCESSED  DATA  BASE 

•  Files  processed  and  manipulated  data  to  BRIEFING  SOFTWARE  through 
terminal 

•  Provides  processed  and  manipulated  data  to  COMMANDER  DECISION  by 
voice  commo  in  response  to  queries 

•  Receives  queries  from  COMMANDER  DECISION  by  voice  commo 
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BRIEFING  SOFTWARE 

•  Stores  processed  and  manipulated  data  received  from  STAFF 
DECISION  through  terminal 

•  Responds  to  queries  received  from  STAFF  DECISION  and  COMMANDER 
DECISION  through  terminals 

•  Provides  processed  and  manipulated  Information  to  STAFF  DECISION 
and  COMMANDER  DECISION  In  response  to  queries  through  terminal 

COMMANDER  DECISION 

•  Receives  processed  and  manipulated  information  from  BRIEFING 
SOFTWARE  through  terminal 

•  Receives  processed  and  manipulated  information  from  STAFF 
DECISION  by  voice  commo 

•  Queries  BRIEFING  SOFTWARE  and  sortes  manipulated  information 
there  (Including  decisions)  through  terminal 

•  Queries  STAFF  OECISION  and  announces  decisions  by  voice  commo 

POST-DECISION 

•  Receives  processed  and  manipulated  data  from  PROCESSED  DATA  BASE 

•  Receives  selected  messages  from  RAW  DATA  BASE 

•  Queries  PROCESSED  DATA  BASE  for  selected  information 

•  Files  processed  Information  In  PROCESSED  DATA  BASE 

•  Queries  RAW  DATA  BASE  for  selected  messages 

•  Composes  outgoing  messages  and  forwards  to  OUTPUT 

OUTPUT 

•  Files  outgoing  messages  In  RAW  DATA  BASE 

•  Transmits,  verifies,  and  tags  outgoing  messages 

INPUTS 

•  Incoming  communications  traffic 
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INTERFACES 

1.  Incoming  messages 

2.  Incoming  messages 

3.  Selected  whole  messages 

4.  Selected  whole  messages 

5.  Requests  for  selected  messages 

6.  Processed  information  and  requests  for  stored  information 

7.  Requested  information 

8.  Requested  information 

9.  Requested  information 

10.  Manipulated  information 

11.  ‘Selected  information  in  following  categories: 

•  Weather  data  and  extrapolations 

•  Terrain  data  and  extrapolations 

•  Friendly  unit  locations,  status,  capabilities 

•  Enemy  unit  locations,  status,  capabilities 

•  Mission 

•  Organization  for  Combat 

•  Order  of  Battle 

•  Logistic  Status 

•  Admin  Status 

•  Courses  of  action  considered 

9  Enemy  intentions/capabilities  considered 

•  Staff  recommendations 

•  Staff  requests  for  any  of  above  or  for  commander's  entries 

12.  Staff  responses  to  commander's  requests  for  information  not 
available  from  BRIEFING  SOFTWARE 

13.  ‘Selected  information  in  following  categories: 

•  Commander's  planning  guidance  and  decisions  entered  at 
Interface  16 

t  Any  categories  entered  at  Interface  11 
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14.  "Selected  Information  In  following  categories: 

•  Any  categories  entered  at  Interface  11 

•  Commander's  planning  guidance  and  decisions  entered  at 
Interface  16 

15.  Requests  to  staff  for  Information  not  available  from  BRIEFING 
SOFTWARE;  planning  guidance  and  decisions  not  enterable  at 
Interface  16. 

16.  "Selected  Information  In  following  categories: 

•  Requests  for  any  categories  entered  at  Interface  11 

•  Requests  for  previously  entered  commander's  planning  guidance 
and  decisions 

•  Planning  guidance  and  decisions 

17.  Requests  for  selected  messages 

18.  Processed  information  and  requests  for  stored  Information 

19.  Outgoing  messages 

20.  Outgoing  messages 

OUTPUTS 

•  Outgoing  communications  traffic 


haunches  during  the  development  phase  —  far  from  it.  He  is 
still  needed  to  provide  advice  and  guidance  to  the  technician,  to 
confer  on  what  the  user  will  find  acceptable,  to  evaluate  the 
proposed  interfaces  —  especially,  displays,  and  to  be  available 
for  "hands-on"  training  especially  for  the  operators  of  the 
equipment.  Don't  forget  that  in  the  example  cited  above  the 
principal  operators  are  the  commander  and  the  senior  staff. 
These  operators  should  be  exposed  to  the  automated  support  almost 
as  soon  as  the  first  displays  can  be  brought  up  on  the  equipment. 
Do  not  wait  until  the  system  is  ready  to  be  operated  in  the 
field.  Initial  exposure  should  be  in  garrison  and  should  be  con¬ 
tinuing  throughout  the  development  phase.  In  addition  to  giving 
the  future  operators  experience  and  confidence  in  computer  sup¬ 
port,  thus  minimizing  "computer  anxiety"  (the  fear  of  bringing 
the  whole  system  down  or  looking  foolish  before  others  because  of 
a  stupid  mistake)  this  early  user  involvement  will  pay  tremendous 
dividends  in  fielding  a  more  useable  system  and  insuring  much 
earlier  user  acceptance. 

Detailed  planning  for  the  demonstration  and  trials  of 
the  initial  devlopment  is  another  activity  that  must  take  place 
during  the  development  phase.  Some  of  the  factors  that  must  be 
considered  in  such  planning  are  discussed  in  the  next  paragraph. 

2.9  INITIAL  DEMONSTRATION  AND  TRIALS 

This  phase  of  the  development  is  without  doubt  the  most 
important  milestone  in  the  entire  effort.  If  the  commander  and 
senior  staff  do  npt  have  the  impression  that  computer  support  can 
improve  their  C  operation,  the  entire  effort  is  clearly  in 
trouble.  Here  are  a  few  rules  that  will  help  avoid  such  an 
outcome: 

1 .  A  thorough  and  complete  plan  for  the  demonstration 
and  trials  must  have  been  completed  while  the  proposed 
computer  support  was  being  developed 

Planning  for  the  initial  trials  is  somewhat  similar  to 
planning  for  an  FTX  or  a  map  exercise.  The  scale  of  the  trials 
will  be  determined  by  the  nature  of  the  applications  being 
tested.  Trying  out  a  movement  order  generator  does  not  require  a 
full-blown  CPX;  trials  of  an  automated  briefing  system  probably 
does  —  at  least  a  reduced  scale  exercise  on  the  grounds  of  home 
station.  There  must  be  means  for  providing  an  information  load 
to  the  system.  How  elaborate  this  is  again  depends  on  the  appli¬ 
cation  being  tested.  This  could  range  from  a  simple  scenario  to 
a  full-blown  Master  Incident  List  to  a  battle  simulation. 

You  must  begin  witjh  a  set  of  test  objectives  tied  di¬ 
rectly  to  the  changes  in  <j  performance  sought  by  means  of  the 
automation  support  being  tested.  These  will  indicate  the  nature 
and  extent  of  the  combat  environment  to  be  simulated  in  order  to 


load  the  TOC  and  to  provide  the  information  needed  to  generate 
the  products  to  be  tested.  In  addition  to  fielding  the  TOC,  the 
plan  must  also  provide  for  the  umpires  or  controllers  necessary 
for  simulating  the  battle  events  and  for  the  data  collectors 
necessary  to  gather  the  quantitative  measures  of  goal  achieve¬ 
ment.  One  reason  for  starting  your  planning  early  is  to  take 
advantage  of  the  assistance  that  can  be  provided  by  TRADOC 
COMBINED  ARMS  TEST  ACTIVITY  ( TCATA )  in  running  the  demonstration 
and  field  trials  —  especially  in  the  area  of  test  data  collec¬ 
tion.  Your  chain  of  command  will  have  information  on  how  to  go 
about  tasking  that  agency. 

2 .  Remember  that  you  are  conducting  an  experiment; 
good  experimentation  requires  a  controlled  (scientists 
would  call  it  "sterile^)  environment.  This  means  you 
must  minimize  the  effects  of  all  variables  except  those 
you  are  trying  to  measure. 

This  second  rule  is  probably  the  one  most  difficult  to 
apply.  Whenever  any  tactical  exercise  is  proposed  there  is 
always  the  tendency  to  hang  on  every  bell  and  whistle  in  the 
training  catalog.  This  must  be  avoided  for  the  initial  trials 
and  is  another  cogent  reason  for  the  personal  involvement  of  the 
commander  and  senior  staff.  The  activity  most  closely  tied  to  Cz 
is,  of  course,  communication,  but  discovering  the  training  defi¬ 
ciencies  of  the  signal  battalion  or  brigade  is  not  the  objective 
of  the  initial  trials  of  the  computer  support  application.  The 
initial  trial  should  take  place  in  garrison  or  with  hard  wired, 
reduced  distance  communication  so  that  the  disturbing  effects  of 
everything  but  the  computer  support  of  operations  is  held  to  a 
minimum.  Later  experimentation  with  alternative  communication 
nets  is  certainly  warranted  to  discover  optimal  CJ  configura¬ 
tions,  but  the  initial  trials  of  a  new  automation  application 
must  eliminate  as  far  as  possible  the  uncontrolled  variables  of  a 
full-blown  communication  system.  The  same  principle  applies  to 
any  other  possible  source  of  impact  on  the  c  system.  The  objec¬ 
tive  of  the  initial  trials  must  be  to  measure  the  change  in 
performance  resulting  from  the  computer  support  to  C2  operations 
--  don*  t  dilute  it  Dy  trying  to  determine  the  effect  of  other 
changes.  Reducing  the  scale  of  the  exercise  to  the  minimum 
needed  to  reach  that  objective  will,  of  course,  reduce  the  expen¬ 
diture  of  limited  training  funds  and,  thus,  the  pressure  to  add 
other  purely  training  objectives. 

3 .  A  detailed  SOP  for  use  with  the  computer  support  must 
have  been  developed?  the  initial  trials  are  a  test  of 
that  SOP  as  well  as  of  the  computer  support. 

You  will  already  have  initiated  compliance  with  the 
third  rule  when  you  analyzed  the  total  system  impact  of  automa¬ 
tion,  especially  the  initial  increment,  during  the  concept  devel¬ 
opment.  Looking  at  the  changes  in  SOP  inevitably  associated  with 
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your  initial  application  was  part  of  that  exercise.  This  needs 
to  be  extended  and  modified  as  the  development  proceeds  to  take 
into  account  the  inevitable  changes  in  requirements  and  new 

insights  provided  as  the  user  gets  involved  during  the  develop¬ 

ment  phase.  The  important  point  is  that  everyone  involved  must 
have  a  clear  idea  of  what  the  application  is  to  be  used  for,  who 

operates  the  equipment,  and  how  it  is  to  be  employed.  Well 

trained  equipment  operators  who  have  already  had  extensive  exper¬ 
ience  with  the  equipment  in  garrison  are  part  and  parcel  of  this 
rule . 

4 .  The  entire  staff  (not  just  the  operators  and  data 
collectors)  must  have  been  oriented  in  advance  as  to 
the  test  objectives,  the  goals  of  the  effort,  and  the 
measures  of  accomplishment  7 

The  entire  staff  --  that  is,  everyone  involved  in  the 
trials  —  must  be  oriented  on  what  the  demonstration  and  trials 
are  all  about.  Not  only  will  this  improve  the  trial,  but  it  is 
amazing  what  insights  toward  improvement  of  the  whole  operation 
can  be  provided  by  knowledgeable  persons  who  have  been  adequately 
briefed  even  though  not  immediately  associated  with  the  computer 
support.  This  rule  also  reinforces  the  importance  of  the  oper¬ 
ating  principle  stated  back  in  paragraph  2.2,  namely,  that  auto¬ 
mation  must  be  phased  in  gradually  in  steps  sufficiently  small 
that  they  can  be  absorbed  by  the  staff  without  completely  chang¬ 
ing  their  method  of  operation  in  one  fell  swoop.  Nothing  can  be 
more  devestating  to  acceptance  of  computer  support  than  trying  to 
impose  too  much  change  in  the  first  step. 

2.10  EVOLUTIONARY  DEVELOPMENT 

Figure  2-9  displays  the  above  procedures  as  a  develop¬ 
ment  cycle  to  emphasize  its  iterative  nature.  After  the  initial 
trials  and  demonstration  and  after  you  have  corrected  the  defi¬ 
ciencies  uncovered  and  modified  your  interim  system  to  incor¬ 
porate  the  lessons  learned,  you  are  ready  to  tackle  the  next 
application s)  .  At  this  stage  it  is  appropriate  to  review  your 
original  concept  to  see  whether  the  experience  gained  with  the 
initial  application  provides  a  basis  for  modifying  the  concept  — 
or  even  for  changing  your  original  priorities.  This  is  even  more 
important  if,  in  the  meantime,  your  unit  has  had  a  change  in 
mission,  or  there  have  been  changes  in  senior  personnel.  Remem¬ 
ber  you  must  be  ever  ready  to  answer  the  question,  "What  has 
automation  done  for  me  lately?" 

In  carrying  through  the  next  iteration  you  will,  of 
course,  apply  not  only  what  you  have  learned  about  system  design, 
but  also  what  you  have  learned  about  how  to  manage  such  an  effort 
in  terms  of  pre-planning,  user  training,  and  how  to  run  demon¬ 
strations  and  trials. 


MODIFY  SOP 


Figure  2-9.  DEVELOPMENT  CYCLE 
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Still  another  important  factor  in  adding  computer  sup¬ 
port  to  your  operation  is  the  matter  of  continuing  user  famil¬ 
iarity  and  training  in  the  use  of  the  computer  support  while 
succeeding  applications  are  under  development.  In  many  cases 
some  portion  of  the  application  already  developed  will  b?  appli¬ 
cable  to  peacetime  operations  in  garrison.  This  use  should  be 
encouraged  and  will  pay  handsome  dividends  in  user  acceptance. 

2.11  INSURING  ACCEPTANCE 

The  whole  purpose  of  this  manual  is  to  assist  you  in 
gaining  initial  and  maintaining  continuing  acceptance  of  the  new 
modes  of  operation  that  will  inevitably  accompany  ^ie  introduc¬ 
tion  and  assimilation  of  automation  into  your  unit  Cz  operations. 
In  particular,  both  the  basic  guidelines  and  task  sequence  dis¬ 
cussed  above  are  efforts  to  encapsulate  the  experiences  of  others 
in  trying  to  absorb  this  new  technology  into  ongoing  operations. 
The  following  observations  and  conclusions  were  arrived  at  as  a 
result  of  visits  to  TACIP  units  both  in  Europe  and  the  CONUS. 

The  following  set  of  principles  summarizes  and  high¬ 
lights  the  experience  of  others  in  making  this  transition 
successfully : 

•  You  must  inspire  confidence  in  the  ability  of 
automated  hardware  and  software  to  assist  in  tacti¬ 
cal  operations.  Don't  bite  off  more  than  you  can 
chew  initially;  it  is  far  better  to  have  people 
panting  for  the  next  application  than  to  swamp  them 
with  more  than  they  can  absorb. 

•  You  must  avoid  even  the  appearance  of  adding  to  the 
workload;  "If  it  doesn't  make  my  job  easier,  it's 
no  good." 

•  You  must  overcome  "computer  anxiety"  by  exposing 
the  ultimate  operator  to  the  equipment  as  soon  as 
possible.  He  must  be  thoroughly  familiar  with  it 
prior  to  the  initial  demonstration  and  trials. 

•  You  must  have  adequate  technical  expertise  avail¬ 
able  .  This  is  part  and  parcel  of  sizing  your 
application s)  to  the  available  resources. 

•  While  you  must  not  let  communication  difficulties 
unduly  affect  your  initial  demonstration  and 
trials,  you  must  be  ever  aware  that  the  ultimate 
constraints  imposed  by  your  communication  net  must 
be  considered  in  your  total  command  and  control 
system  design. 

Figure  2-10  illustrates  the  applications  of  these  principles  to 
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Figure  2-10.  APPLICATION  OF  ACCEPTANCE  PRINCIPLES 
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the  individual  tasks  in  the  development  cycle. 


Familiarity  with  the  confidence  in  a  system  seem  to  be 
the  primary  factors  in  user  acceptance  --  that  is,  assuming  the 
system's  utility  in  aiding  user  functions  has  been  perceived.  If 
the  system  is  perceived  to  create  additional  workload,  user 
resistance  will  be  difficult  to  overcome. 

When  the  user  becomes  aware  of  how  the  system  will 
assist  him  in  the  performance  of  his  job,  the  next  hurdle  seems 
to  be  overcoming  "computer  anxiety."  The  latter  is  primarily  the 
result  of  two  common  fears:  the  fear  of  pushing  the  wrong  button 
and  thus  causing  system  failure,  and  the  fear  that  when  some 
simple  error  is  made  the  whole  world  will  know  (or  the  fear  of 
not  knowing  exactly  who  will  know)  .  Developing  a  familiarity 
with  the  computer  to  overcome  these  fears  is  the  first  step  in 
training.  Training  cannot  be  effective  until  the  user  is  at  ease 
and  comfortable  with  the  machine. 

Another  major  factor  in  user  acceptance  is  confidence  in 
the  system.  This  is  related  to  perception  of  utility.  When  the 
user  is  not  confident  in  the  system  he  takes  precautions  against 
its  failure,  i.e.,  maintains  the  manual  system  also.  This 
creates  additional  work  and  the  computer,  because  of  its  per¬ 
ceived  lack  of  reliability,  is  blamed  for  the  increase.  To  some 
extent  increased  familiarity  will  lead  to  increased  confidence; 
however,  the  system  must,  in  fact,  be  reliable.  Periodic  fail¬ 
ures,  loss  of  data,  and  nonavailability  when  needed  will  be 
amplified  in  the  mind  of  the  user  and  must  be  minimized  to 
develop  confidence  that  the  system  is,  and  will  be,  a  worthwhile 
tool  for  the  user. 

Expertise  in  hardware,  software,  and  systems  analysis 
must  be  available  to  the  project  manager.  Command  interest  in  a 
project  is  not  sufficient  if  it  doesn't  extend  to  providing  the 
expertise  required  to  accomplish  the  desired  results.  Develop¬ 
ment  is  slow  and  generally  insufficient  when  developers  have  to 
learn  as  they  are  developing  the  system.  In  order  for  these 
programs  to  have  significant  results  in  the  near  term,  expertise 
must  be  made  available  so  that  the  developer  can  respond  to  user 
desires  in  defining  the  problem,  developing  a  solution,  testing 
that  solution,  and  training  the  users. 

The  user's  exposure  to  the  computer  system  must  be  con¬ 
tinuous  in  order  to  develop  and  maintain  familiarity  with  its 
use.  System  applications  must  be  developed  for  use  in  garrison 
to  facilitate  this.  A  system  which  is  used  only  in  field  opera¬ 
tions  creates  a  training/relearning  problem  prior  to  and  in  the 
early  stages  of  every  exercise.  "User  friendly"  is  a  catchy 
phrase  which  has  different  meanings  for  different  people  and 
always  requires  tremendous  overhead  within  the  computer  system. 
We  are  a  long  way  from  having  computer  systems  which  can  carry  on 


human-like  conversations  and,  therefore,  are  forced  to  learn  to 
talk  to  the  computer  in  ways  it  can  understand.  If  we  expect  the 
computer  to  be  of  use  in  a  "come  as  you  are"  war,  users  must  be 
totally  familiar  with  and  comfortable  with  the  system.  There 
will  be  no  time  to  get  up  to  speed  in  its  use. 

Communications  capability  is  rapidly  becoming  the  limit¬ 
ing  factor  in  the  transfer  or  exchange  of  data  in  organizations 
using  automated  data  systems.  In  order  to  realize  the  full 
benefit  of  computers,  data  must  be  transferred  between  locations 
rapidly.  Decision  support  in  tactical  command  and  control  can 
require  large  data  transfers,  especially  when  such  transfers  are 
not  limited  to  the  dynamic  data  elements  and  include  large  blocks 
of  relatively  stationary  data  which  could  have  been  stored 
locally.  It  has  become  evident  in  some  of  the  initiatives  that 
hand  carrying  large  files  on  magnetic  disk  could  relieve  system 
congestion  and  even  save  time  in  the  transfer.  Possibilities  for 
communication  upgrades  must  be  examined  and  fielded  to  take  full 
advantage  of  the  automated  data  capabilities. 
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SECTION  3 


THE  TACTICAL  COMMAND  CONTROL  (C2)  SYSTEM 


In  order  to  put  your  problem  into  context  and  to  have  a 
common  basis  for  assessing  potential  payoffs  relative  to  costs 
and  risks,  it  is  necessary  to  describe  the  tactical  CT  system  in 
information  system  terms.  You  may  well  wonder  why  we  have  to  go 
through  the  effort  of  dissecting  TOC  operations  on  the  basis  of 
information  processing  rather  than  the  much  more  common  classifi¬ 
cations  based  on  the  kinds  of  information  being  processed  (admin, 
intel,  ops,  log,  and  all  their  subclassifications)  or  on  a  basis 
of  input  and  output  message  types.  The  reason  for  this  approach 
is  that  we  need  a  tool  in  the  form  of  a  model  of  TOC  operations 
which  is  independent  of  the  kind  of  information  being  processed 
and  which  applies  to  all  input  messages  that  need  to  be  processed 
as  well  as  to  every  output  that  needs  to  be  produced.  Such  a 
model  can  be  used  to  portray  the  information  processing  opera¬ 
tions  of  any  decision  making  note  in  the  tactical  system 
whether  it  be  a  TOC  or  in  some  other  element  of  the  CP.  For 
those  of  you  who  have  decided  to  read  this  section  before  tack¬ 
ling  the  "how  to"  portion  of  the  manual  in  Section  2,  having  such 
a  model  of  TOC  operations  will  be  extremely  useful  when  we 
address  the  problem  of  developing  concepts  for  the  improvement  of 
the  C£  system  through  automation  and  evaluating  such  concepts  in 
terms  of  their  costs  and  risks. 

2 

The  remainder  of  this  section  describes  the  tactical  C 
system  as  an  information  system  by  posing  and  answering  the  nine 
questions  shown  immediately  below. 


THE  TACTICAL  COMMAND  CONTROL  (C2)  SYSTEM 


Section  # 

(Page  #) 

Questions 

3.1 

3-2 

What  is  it? 

3.2 

3-2 

What  does  it  do? 

3.3 

3-3 

What  is  it  for? 

3.4 

3-3 

What  does  it  look  like? 

3.5 

3-3 

How  does  a  TOC  process  information? 

3.6 

3-11 

How  does  it  differ  from  business 
management? 

3.7 

3-16 

What's  wrong  with  it? 

3.8 

3-17 

How  can  automation  help? 

3.9 

3-21 

What's  an  example  of  automation? 

3.1 


WHAT  SYSTEM  IS  IT? 


There^ seems  to  be  little  agreement  on  what  precisely  is 
the  tactical  Or  system;  observers  tend  to  describe  the  portion  of 
the  elephant  nearest  them.  The  engineer  refers  to  an  assemblage 
of  hardware;  the  ADP  system  designer  refers  to  a  collection  of 
hardware  and  software.  The  user  tends  to  describe  it  at  a  parti¬ 
cular  echelon  of  command  or  as  a  "functional"  system,  e.g.,  an 
intelligence  system,  a  fire  support  system,  or  a  communication 
system.  At  the  other  extreme  there  is  frequent  confusion  between 
the  command  control  system  and  the  forces  being  commanded  and 
controlled.  For  our  purposes  let  us  define  the  Cz  system  to 
include  commanders  at  all  echelons,  their  staffs,  and  all  commu¬ 
nications,  sensors,  personnel,  equipment,  facilities  and  proce¬ 
dures  used  in  planning,  directing,  coordinating,  and  controlling 
the  assigned  forces.  A  convenient  analogy  is  that  the  Cz  system 
is  essentially  the  nervous  system  of  the  tactical  force.  It 
informs  when  the  force  needs  replenishment  or  rest.  It  controls 
and  coordinates  the  muscles.  Above  all,  it  is  the  repository  of 
force  goals  and  past  experience  and  makes  decisions  to  take 
actions  to  achieve  those  goals. 

3.2  WHAT  DOES  IT  DO? 

It  is  useful  to  examine  the  functions  of  combat  in  the 
light  of  the  above  general  definition  to  see  if  they  can  help  us 
differentiate  between  the  Cz  system  and  the  remainder  of  the 
force  in  a  functional  sense.  Following  is  a  commonly  accepted 
list  of  combat  functions  together  with  their  inputs  (what  trig¬ 
gers  the  function?)  and  outputs  (does  it  produce  physical  action 
or  information?). 


INPUT 


COMBAT  FUNCTION  OUTPUT 


Information 

Information 

Information 


Fire 

Move 

Support 


Physical  Action 
Physical  Action 
Physical  Action 


Physical  Action 

Information 

Information 


Sense 

Communicate 
Plan,  Direct, 
Coordinate,  Control 


Information 

Information 

Information 


This  listing  clearly  differentiates  the  last  three  functions, 
which  output  information,  from  the  first  three  which  output 
physical  action.  It  is  these  last  three  information  outputting 
functions  that  have  been  included  in  tiie  CZ  system  definition  of 
the  preceding  paragraph.  Thus,  the  Cz  system  is  an  information 
system.  What  does  it  do?  It  processes  information. 
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3.3 


WHAT  IS  IT  FOR? 


The  key  to  answering  this  question  lies  in  the  operative 
words  of  the  preceding  definition:  planning ,  directing,  coordi¬ 
nating  ,  and  controlling .  All  of  these  activities  Involve  the 
gathering,  transmitting ,  and  processing  of  information  to  reduce 
uncertainty,  to  facilitate  decision  making  under  conditions  of 
uncertainty,  and  to  supervise  the  execution  of  decisions.  The 
principal  nodes  of  this  system  are  the  commanders  and  staffs  at 
the  several  echelons  of  command.  It  is  these  nodes  which: 

•  Collect,  sort,  aggregate,  and  organize  information 
for  decision  making. 

•  Interpret,  project,  and  extrapolate  information  and 
suggest  and  evaluate  alternative  courses  of  action, 
make  decisions,  and 

•  Prepare  and  distribute  instructions  for  implement¬ 
ing  decisions  (plans,  orders,  directives)  and 
monitor  the  execution  of  decisions. 

3.4  WHAT  DOES  IT  LOOK  LIKE? 

2 

Figure  3-1  is  a  schematic  of  tactical  C  system  at  a 
single  echelon  of  command.  Central  to  the  system  is  the  tactical 
operations  center  (TOC)  containing  a  data  base  with  status,  mis¬ 
sion  and  plans.  Its  many  functions  have  been  aggregated  into 
situation  recognigion  and  action  selection.  It  is  coupled  to  the 
outside  world  through  effectors  that  initiate  physical  actions 
which  produce  real  events.  These  produce  observables  which  may 
be  fed  back  as  information  by  sensors.  There  is,  of  course,  a 
hierarchy  of  such  loops  in  the  military  structure.  At  each 
echelon  this  system  tries  to  achieve  the  set  of  goals  prescribed 
in  its  mission. 

3.5  HOW  DOES  A  TOC  PROCESS  INFORMATION? 

The  individual  decision  node  (TOC),  as  indicated  in 
Figure  3-1,  can  be  thought  of  as  a  black  box  embedded  in  a  commu¬ 
nication  net.  This  black  box  has  at  its  boundaries  easily  dis- 
cernable  inputs  and  outputs.  However,  inside  the  black  box  some 
sort  of  transformation  takes  place  which  we  can  label  simply 
"processing"  so  that  the  TOC  as  a  whole  can  be  described  as  an 
input-process-output  or  IPO  model.  The  inputs  and  outputs  are 
observable  and  can  be  specified  but  the  internal  processes  are 
not  observable  nor  can  they  be  specified  until  we  take  a  look 
inside  the  black  box.  But  we  also  know  that  the  TOC  is  populated 
by  a  group  of  individuals  and  a  set  of  equipments  used  by  the 
individuals  to  facilitate  the  interior  processing.  Groups  of 
individiuals  engaged  in  such  information  processing,  just  like 
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Figure  3-1 .  A  SCHEMATIC  OF  THE  C2  SYSTEM 
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groups  engaged  in  any  other  joint  activity  tend  to  organize  them¬ 
selves  into  specialties.  A  division  of  labor  follows  which  takes 
advantage  of  the  special  skills  and  experience  —  and  place  in 
the  pecking  order  --  of  each  individual.  In  other  words,  an 
organizational  structure  emerges.  Specialized  sub-clusters  of 
individuals  are  formed.  The  sub-clusters  referred  to  here  are 
quite  separate  from  the  usual  division  of  the  TOCs  of  larger 
units  into  separate  staff  sections  and  groups  of  specialists  such 
as  the  FSE ,  DAME,  etc.  The  sub-groups  resulting  from  the  divi¬ 
sion  of  information  processing  labor  exist  within  each  of  the 
above  and  consist  of  personnel  with  different  skill  levels  such 
as  RTOs ,  clerks,  NCOS ,  and  officers.  Each  such  sub-cluster  and, 
finally,  each  individual  can  be  thought  of  as  an  IPO  model  with 
observable  inputs  and  outputs.  In  such  a  structure,  information 
must  be  passed  between  sub-clusters  and  between  individuals  and 
to  data  storage  devices  (files,  maps,  displays,  terminals).  An 
examination  of  these  internal  inputs  and  outputs  can  provide 
insights  into  the  nature  of  the  information  processes  actually 
being  performed.  This  amounts  to  breaking  the  TOC  down  into  a 
hierarchy  of  IPO  models  in  which  the  individual  is  the  lowest 
level  of  concern.  In  the  next  paragraph  we  shall  develop  this 
notion  at  the  sub-cluster  level  and  in  the  following  paragraphs 
we  shall  proceed  to  the  level  of  the  individual  as  a  component  of 
the  TOC.  In  this  way  we  can  dissect  the  total  TOC  processing, 
first  into  functions  performed  by  sub-clusters,  and  then  into 
individual  processes  performed  by  individuals  in  conjunction  with 
data  storage  and  retrieval  devices. 

3.5.1  Sub-Cluster  Functions 


The  major  functions  that  can  be  distinguished  within  the 
sub-cluster  are  input  and  output,  pre-  and  post-decision  proces¬ 
sing,  and  decision  making.  These  are  illustrated  in  Figure  3-2. 
Incoming  messages  are  throughput  by  the  input  function  to  a  raw 
data  base  (message  file)  and  to  the  pre-decision  function.  The 
pre-decision  function  extracts  data  from  the  incoming  messages 
and  enters  it  in  structured  form  into  the  processed  data  base 
thereby  creating  and  continually  updating  the  useable  data  base 
(section  files  and  displays  in  the  manual  mode).  The  decision 
function  extracts  information  in  structured  form  from  the  data 
base,  manipulates  it  and  augments  it  by  adding  new  structures, 
making  assumption  to  cover  the  gaps,  and  reinterpreting  the 
results  in  order  to  select  the  action(s)  to  be  implemented.  The 
post-decision  function  converts  decisions  into  messages  and 
further  updates  the  data  base.  The  output  function  throughputs 
the  messages  into  the  information  stream  and  into  the  message 
file. 


Lest  one  fall  into  the  trap  of  regarding  the  TOC  as  an 
enirely  reactive  entity,  one  must  recognize  the  arrows  shown  in 
Figure  3-2  indicate  only  information  transfers  among  the  com¬ 
ponents  of  the  TOC.  They  neither  imply  that  this  is  a  continuous 
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Figure  3-2.  TOC  FUNCTIONAL  SUB-GROUPING 
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process  nor  that  every  input  produces  an  output,  nor  even  that 
all  outputs  can  be  traced  to  specific  inputs.  Just  as  individual 
human  reactions  are  not  necessarily  always  triggered  by  external 
stimuli,  group  outputs  can  be  triggered  by  internal  stimuli  which 
can  vary  in  complexity  from  periodic  reports  triggered  by  an 
internal  clock  to  actions  taken  as  a  result  of  profound  insight 
or  hypotheses  generated  long  after  the  arrival  of  the  latest 
segment  of  raw  data  that  has  been  considered. 

3.5.2  Individual  Processes 


The  division  of  labor  does  not,  however,  stop  with  the 
functions  identified  in  Figure  3-2.  The  functions  identified 
there  are  not  always  performed  by  a  single  individual  so  that 
processes  comprising  each  of  these  functions  can  also  be  identi¬ 
fied.  Figure  3-3  expands  the  model  to  show  the  information 
processes  inherent  in  each  function.  The  following  table  de¬ 
scribes  its  components,  its  attributes,  and  the  product  on  which 
it  operates.  This  will  be  done  in  the  sequence  indicated  in  the 
figure  rather  than  alphabetically.  Although  an  effort  will  be 
made  to  keep  the  discussion  general,  i.e.,  so  that  it  applies 
both  to  manual  and  ADP  assisted  groups,  the  initial  discussion 
will  concentrate  on  the  manual  mode;  changes  resulting  from 
automation  will  be  discussed  later.  The  definitions  of  the  model 
components  follow: 

COMMAND  CONTROL  GROUP:  An  assemblage  of  more  than  one  individual 
and  the  equipment  (communication  terminals,  files,  displays,  data 
processing  equipment,  etc.)  needed  to  function  as  a  decision  node 
in  a  tactical  command  control  system.  Members  of  the  group  are 
collocated  so  that  non-verbal  communications  are  facilitated. 
Conversely,  members  are  in  some  degree  shielded  from  non-verbal 
communication  with  nonraembers  of  the  group.  Military  staffs  of 
larger  units  usually  function  as  a  number  of  separate  and  dis¬ 
tinct  command  control  groups  (staff  sections). 

EXTERNAL  INFORMATION  STREAM:  This  includes  all  information 
received  by  the  command  control  group  from  sources  outside  itself 
and  all  transmitted  by  the  group  to  recipients  outside  itself. 
It  includes  all  means  of  communication  (oral,  written,  electri¬ 
cal,  gestures)  and  includes  information  to  and  from  other  command 
control  groups  (staff  sections)  within  the  same  headquarters  -- 
to  include  the  grim  visage  of  the  CG  who  is  still  waiting  for  the 
chopper  he  ordered  30  minutes  ago.  Most  of  the  information  flow¬ 
ing  in  this  external  stream  is  in  the  form  of  communications 
traffic . 
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MESSAGE:  An  ordered  selection  from  an  agreed  set  of  signs 

(alphabet)  intended  to  communicate  information. 

RECEIVE:  The  process  of  accepting  the  string  of  signs  or  symbols 
that  constitute  a  message  —  or  the  process  of  making  a  one-for- 
one  transformation  of  the  incoming  string,  e.g.,  copying  an  in¬ 
coming  voice  message  or  repeating  aloud  an  incoming  message. 
This  process  does  not  include  transforming  the  string  of  symbols 
into  information. 

VERIFY:  The  process  of  ensuring  that  the  accepted  string  of 
signs  or  symbols  agrees  precisely  with  the  string  to  be  trans¬ 
mitted  by  the  sender.  This  process  may  require  transmission  of 
procedural  signs  or  even  retransmission  of  the  message  string  by 
the  receiver.  It  is  this  process  which  reduces  uncertainty  in 
the  sense  of  Shannon's  Communication  Theory. 

TAG:  To  affix  an  identifier  (frequently  a  sequence  number)  to  a 

message  to  facilitate  retrieval  from  the  raw  data  base. 

RAW  DATA  BASE:  A  file  containing  incoming  and  outgoing  messages 
processed  only  through  the  verification  and  tagging  stages. 
Example:  Staff  Journal. 

SORT:  To  arrange  entire  messages  or  segments  of  messages  accord¬ 

ing  to  a  predetermined  classification  scheme.  This  is  the  lowest 
level  process  requiring  some  perception  of  message  content  —  at 
least  at  the  level  of  the  classification  scheme.  Example: 
Extracting  unit  location  from  a  SITREP. 

ASSOCIATE:  To  relate  a  package  of  sorted  information  to  other 

information  in  the  same  or  allied  class.  Example:  Is  the  1st 

Battalion  of  the  32nd  Tank  Regiment  part  of  the  20th  Guards  Tank 
Division? 

AGGREGATE/ORGANIZE:  To  combine  associated  information  and  array/ 

display  it  in  a  manner  that  facilitates  the  decision  processes. 
Example:  Update  the  Order  of  Battle. 

INTERPRET/VALIDATE:  To  hypothesize  cause-and-ef feet  relation¬ 

ships  between  ordered  sets  of  information  and  to  assess  the 
probability  of  their  correctly  representing  ground  truth.  Since 
ground  truth  is  usually  not  accessible,  validity  must  be  assessed 
in  terms  of  consistency  with  past  experience,  or  against  indepen¬ 
dently  derived  hypotheses  from  within  or  outside  the  group.  This 
process  is  significantly  different  from  "reduction  of  uncer¬ 
tainty"  in  the  Shannon  sense.  Example:  How  can  the  2/31  Batta¬ 
lion  continue  to  advance  at  over  5  km/hr  against  two  regiments 
when  it  has  sustained  a  reported  60  percent  casualties? 

EVALUATE/COORDINATE:  To  determine  whether  the  perceived  situa¬ 

tion  warrants  consideration  of  taking  further  action  or  of  shar- 
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ing  the  perception  with  another  command  control  group  or  of  both. 
Example:  Does  the  gap  apparently  opening  up  on  our  right  flank 
warrant  issuing  a  frag  order,  or  notifying  the  adjacent  unit,  or 
both? 

PROJECT/EXTRAPOLATE:  To  estimate  probable  future  situations 
based  on  current  or  predicted  trends.  Example:  Where  and  when 
must  I  lay  on  the  next  ammunition  resupply  operation  if  present 
expenditure  and  movement  rates  continue? 

GENERATE  ALTERNATIVES:  To  postulate  alternative  courses  of 
action  for  both  friendly/enemy  forces  which  could  conceivably 
lead  to  mission  accomplishment.  Enemy  missions  must  usually  be 
inferred  or  multiple  missions  within  his  capability  must  be 
considered.  The  latter  process  is  usually  referred  to  as,  "de¬ 
termining  enemy  capabilities." 

DECIDE:  The  process  of  determining  which  of  the  alternatives 
considered  is  most  likely  to  yield  the  greatest  success  in  accom¬ 
plishing  the  assigned  mission. 

ASSOCIATE  (POST-DECISION  PROCESSING):  To  relate  fully  processed 
information  during  preparation  of  output  messages,  and  to  update 
impacted  data  bases.  Example:  The  decision  "main  effort  on  the 
right"  might  be  transformed  into  "2d  Brigade  attacks  in  zone, 
makes  main  effort  ..  priority  of  fires  to  2d  Brigade." 

REAGGREGATE:  To  combine  fully  processed,  relevant,  and  needed 
information  into  preparation  of  an  output  message.  Example: 
Revise  the  Organization  for  Combat  in  accordance  with  the 
decision . 

SORT  ( POST-DEC  IS  ION  PROCESSING):  To  arrange  segments  of  an 
outgoing  message  in  the  selected  format  and  to  determine 
d istribut ion . 

TRANSMIT:  The  process  of  entering  into  the  external  information 
stream  the  string  of  signs  or  symbols  that  constitute  the 
message . 

VERIFY  (OUTPUT  PROCESSING):  Same  as  for  the  input  processing. 


3.5.3  Information  Processes  Related  to  Military  Decision 
Making 

It  is  instructive  to  examine  the  military  decision  mak¬ 
ing  process  in  terms  of  the  model  described  above  to  see  whether 
all  of  the  decision  making  process  can  be  expressed  in  those 
terms.  Since  the  decision  making  process  (as  described  in 
Chapter  5  (Figure  5-1)  of  FM  101-5,  Coordinating  Draft,  3  June 
1981  and  in  CGSC  text,  FUNDAMENTALS  OF  STAFF  OPERATIONS,  pp 
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191-208,  April  1983)  is  the  single  most  complex  activity  of 
tactical  staffs,  a  check  to  see  whether  the  model  adequately 
represents  this  activity  will  insure  its  comprehensiveness. 
Figure  3-4  does  this  at  the  level  of  the  functional  subgrcjps. 
The  steps  in  the  military  decision  process  are  listed  across  the 
bottom;  the  functions  are  the  row  headings.  The  function(s) 
required  to  perform  each  step  in  the  decision  process  is  indi¬ 
cated  by  an  entry  in  the  appropriate  box,  the  entry  indicating 
whether  that  function  is  performed  by  the  commander  or  the  staff. 
The  information  transfer  between  functions  is  indicated  by  an 
arrow  and  the  nature  of  each  transfer  is  indicated. 

In  Figure  3-5,  a  similar  check  is  made  at  the  informa¬ 
tion  process  level.  In  the  left  column  are  listed  the  ten  steps 
of  the  decision  process.  The  next  seventeen  columns  list  the 
previously  defined  information  processes.  In  the  right-hand 
column  are  listed  the  tangible  products  produced  at  each  step. 
This  last  listing  is  reasonably  complete;  not  all  of  these  prod¬ 
ucts  are  produced  for  every  major  decision,  depending  on  time 
available  and  echelon.  The  check  mark  entries  indicate  which 
information  processes  are  sufficient  (not  always  necessary)  to 
carry  out  the  step  and  to  produce  the  indicated  product(s).  The 
single  or  double  check  is  a  judgment  call  as  to  the  relative 
effort  usually  required  for  the  indicated  process  with  reference 
to  a  single  decision.  The  figure  does  assume  a  sufficiently  well 
trained  staff  so  that  the  commander  does  not  have  to  perform  much 
pre-  or  any  post-decision  processing. 

To  go  one  level  of  detail  deeper,  Figure  3-6  compares 
the  sequence  of  steps  in  the  commander's  estimate,  as  formulated 
on  pages  F-2  to  F-8  of  FM  101-5,  with  the  five  decision  pro¬ 
cesses.  It  will  be  noted  that  not  only  is  there  a  good  fit,  but 
the  sequence  is  the  same  as  postulated  in  Figure  3-3. 

3.6  HOW  DOES  IT  DIFFER  FROM  BUSINESS  MANAGEMENT? 

In  looking  about  for  other  similar  activities  to  which 
automation  has  already  been  applied  with  some  success,  one  is 
struck  with  the  similarity  between  a  business  office  and  a  com¬ 
mand  post.  The  function  of  both  is  to  regulate  the  activities  of 
subordinates  through  decisions/orders  to  accomplish  selected 
goals.  Both  contain  the  following  elements: 

•  One  or  more  decision  makers 

•  Professional  support  staff 

•  Secretarial  staff 

•  Equipment  and  office  machines 

•  Internal  working  environment  (operating  methods, 

procedures,  etc.) 

There  are,  however,  some  significant  differences  which 
must  be  kept  in  mind  rather  than  trying  blindly  to  copy  the 
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methods  of  business  management.  These  arise  from  the  vastly 
different  envisionment  within  which  these  organizations  operate, 
the  most  significant  of  which  is  the  time  compression  associated 
with  the  conduct  of  battle.  Comparing  a  modern  division  com¬ 
prising  nearly  20,000  men  with  an  industrial  organization  of 
comparable  size  or  capital  investment  discloses  significant 
differences: 

•  Continuity  of  Operations 

Business  operations  are  more  or  less  continuous. 
"Emergencies"  normally  comprise  a  small  percentage  of  day-to-day 
operations  Battles,  on  the  other  hand,  are  highly  intermittent 
and  unique.  Commanders  and  staffs  are  concerned  with  planning 
for  and  handling  "emergencies."  In  industry  a  base  of  management 
experience  can  be  built  which  permits  "management  by  exception," 
running  battles  is  the  "management  of  exceptions." 

•  Command  Control  in  Mobile  Warfare 

The  mobility  of  modern  combat  forces  is  a  principal 
driver  of  many  of  the  special  requirements  of  a  tactical  C 2 
system.  The  control  of  forces  executing  highly  mobile  operations 
requires  an  extremely  dynamic  data  base  both  as  a  result  of  enemy 
induced  changes  to  the  situation  and  f rom 2 frequent  changes  in 
mission  and  force  structure.  Finally,  the  c  system,  just  as  any 
other  portion  of  thg  force,  is  under  enemy  attack  so  that  the 
capability  of  the  C*  system  itself  varies  over  time.  This  is 
exacerbated  by  the  frequent  need  to  relocate  command  posts  there¬ 
by  reducing  the  CP  duty  cycle. 

•  Planning  Horizon 

The  same  factors  that  necessitate  the  requirement  for  a 
highly  dynamic  data  base  also  require  s  short  planning  horizon. 
The  division  planning  horizon  is  normally  24  hours.  Compare  this 
with  the  typical  planning  horizon  of  1-5  years  for  a  comparable 
industrial  organization. 

•  Provision  for  Centralized  and  Decentralized  Control 

Natural  limits  on  the  span  of  control  demand  a  hier¬ 
archical  management  structure,  which  implies  that  some  measure  of 
decentralization  will  always  exist.  This  is  equally  true  for  the 
military.  There  are,  however,  two  additional  factors  contribu^ 
ting  to  the  requirement  for  a  tightly  structured  hierarchical  CZ 
system.  The  first  of  these  arises  from  the  high  variability  in 
the  degree  of  uncertainty  that  exists  under  different  tactical 
situations.  Under  conditions  whereby  only  subordinate  commanders 
can  acquire  the  information  required  for  rapid  and  responsive 
decisions,  control  must  be  decentralized.  Under  conditions  which 
require  extremely  tight  coordination  between  all  elements  of  the 
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division,  control  must  be  highly  centralized.  This  requirement 
for  rapid  change  in  the  very  nature  of  the  control  being  exer¬ 
cised  augments  the  need  for  a  hierarchical  structure.  The  second 
factor  is  the  fact  that  the  Cz  structure  itself  can  be  degraded 
by  enemy  action;  thus  a  decentralized  structure  must  exist  to 
provide  continuous  command  and  control  in  the  event  of  losses  of 
individual  nodes  or  links.  The^e  requirements  demand  that  the 
tactical,  automation  supported  C z  system  be  compatible  with  both 
centralized  and  decentralized  operations  with  minimal  transition 
effort . 

3.7  WHAT’S  WRONG  WITH  IT 

To  put  it  crudely  but  succinctly,  "It's  simply  too  damn 
slow."  Two  projections  of  the  nature  of  future  combat  combine  to 
emphasize  the  necessity  for  reducing  Cz  timelines  and  increasing 
the  accessibility  and  accuracy  of  the  data  base  used  for  deci¬ 
sion-making.  The  first  is  the  extension  of  the  battlefield  both 
in-depth  and  forward  in  the  time  dimension  as  described  in  recent 
TRADOC  writings.  The  second  is  the  projection  of  future  battle 
dynamics  set  forth  in  TRADOC ' s  /.iiland  Battle  doctrine.  Attacks 
against  follow-on  echelons  are  made  with  the  objective  of  creat¬ 
ing  "windows  for  action"  during  which  friendly  superiority  exists 
and  the  initiative  can  be  seized  with  enough  time  to  act.  Recog¬ 
nition  of  the  "windows"  created,  execution  of  these  attacks,  and 
execution  of.coordinated  actions  at  the  PLOT  combine  to  present  a 
monumental  Cz  problem  for  which  every  possible  assistance  must  be 
provided  to  the  commander. 

Essential  to  the  success  of  U.S.  forces  is  the  ability 
to  disrupt  the  flow  of  enemy  combat  power  and  strike  quickly 
given  favorable  conditions.  This  clearly  implies  recognition, 
coordination  and  decision  processes  which  are  beyond  the  capa¬ 
bility  of  current  procedures  to  execute  on  a  sustained  basis. 
Also  implied  are  continuous  calculations  —  movement  times  for 
forces  of  both  sides,  force  ratios,  damage  predictions,  fire  plan 
coverage,  logistical  requirements,  and  so  on  --  for  numerous 
courses  of  action,  repeated  at  frequent  intervals.  Failure  to 
properly  monitor  these  fundamental  relationships  and  requirements 
can  negate  timely  recognition  of  an  opportunity  and/or  the  abil¬ 
ity  to  capitalize  when  presented.  It  is  through  such  calcula¬ 
tions  that  the  opportunity  can  be  anticipated  rather  than  reacted 
to. 

This  need  for  improved  timeliness  and  quality  in  tac¬ 
tical  decision-making  leads  directly  to  the  following  bajic  goals 
to  be  achieved  through  the  incorporation  of  ADP  in  the  c  system: 

2 

1.  Reduce  timelines  throughout  the  tactical  C  system, 
but  especially  the  response  times  of  the  decision¬ 
making  nodes  (TOC)  . 
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2 


Improve  the  capability  to  "manage  uncertainty," 
i.e.,  provide  decision  aids  which  facilitate  selec¬ 
tion  of  alternatives  with  the  highest  probability 
of  success. 

3.  Reduce  the  uncertainty  of  the  data  base  (basis  for 
decision-making)  through  better  management  of  data 
collection  and  processing. 

The  achievement  of  such  a  broad  set  of  goals  is  of 
course  impossible  in  one  fell  swoop  across  the  entire  spectrum  of 
Cz  activities.  In  fact,  one  of  your  first  tasks  will  be  the 
development  of  a  concept  which  prioritizes  the  list  of  feasible 
applications  of  automation  into  a  phased  series  of  changes  that 
insure  substantial  progress  toward  goals  at  acceptable  cost  and 
risk . 


3.8  HOW  CAN  AUTOMATION  HELP? 

We  have  now  reached  the  point  where  we  can  develop  some 
answers  to  questions  such  as,  "Can  automation  really  help  us 
achieve  the  goals  stated  in  the  preceding  paragraph  and,  if  so, 
why  and  how?"  To  do  so  we  will  use  the  model  of  TOC  (or  any 
other  decision  node)  information  processing  developed  in  para¬ 
graph  3.5  above.  Since  this  was  developed  to  provide  a  complete 
statement  of  the  information  processes  needed  to  process  any 
incoming  message  or  to  produce  any  needed  output  of  a  C 2  decision 
node,  it  will  be  useful  to  examine  the  question  of  the  relative 
capability  of  man  and  the  machine  to  perform  these  processes. 
Our  intuition  tells  us  that  there  are  probably  a  number  of  pro¬ 
cesses  that  the  machine  cannot  perform,  but  that  there  are 
undoubtedly  some  which  it  can  perform  much  better  than  man.  We 
should  also  look  at  the  question  of  which  of  these  processes  can 
probably  be  performed  even  better  when  a  machine  supports  a  human 
processor . 

Such  comparison  is  made  in  Table  3-1.  Listed  in  the 
first  column  at  the  left  are  the  information  processes  required 
for  the  input,  pre-decision,  and  decision  functions.  The  pro¬ 
cesses  required  for  the  post-decision  and  output  functions  have 
not  been  repeated  since  they  are  the  same  as  for  inputs,  but  in 
essentially  inverse  order.  The  second  column  lists  the  dominant 
characteristics  of  unaided  man  in  carrying  out  each  process  while 
the  third  column  lists  the  dominant  characteristics  of  the  auto¬ 
mated  system  (machine)  by  itself.  The  fourth  column  rates  the 
potential  payoff  of  combining  the  complementary  capabilities  of 
both  man  and  machine,  i.e.,  of  providing  computer  support  to  the 
process . 


The  table  shows  that  complete  automation  of  the  first 
three,  input  and  output,  processes  offers  substantial  improvement 
except  for  the  loss  of  the  "personal"  dimension  so  clearly  a 
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basic  component  of  voice  communication.  The  latter  can,  of 
course,  be  extremely  important  in  commander  to  commander  ex¬ 
changes.  Nevertheless,  the  bulk  of  the  routine  traffic  could  be 
handled  far  more  rapidly  and  expeditiously  over  digital  links  — 
provided  the  rest  of  the  system  could  handle  the  increased  infor¬ 
mation  load^  One  of  the  corollaries  to  Parkinson's  Laws  is  that 
military  traffic  inevitably  expands  to  the  limits  of  the  avail¬ 
able  channel  capacity. 

We  note  that  the  next  three  processes,  which  are  invoked 
for  pre-and  post-decision  processing,  are  distinctly  complemen¬ 
tary  with  respect  to  man  vs  machine  processing.  Only  man  can 
provide  the  basis  for  sorting  and  the  needed  sorting  keys,  the 
association  algorithms,  and  the  formats  and  algorithms  needed  for 
aggregating  and  organizing .  On  the  other  hand,  man  is  very  slow 
and  error  prone  in  the  actual  conduct  of  these  processes,  while 
the  machine  is  very  fast  and  error  free  once  the  needed  sorting 
keys,  algorithms,  and  formats  have  been  provided.  Clearly,  these 
are  processes  which  can  profit  from  joint  man-machine  processing. 
Fortunately,  too,  the  bulk  of  the  human  processing  required  can 
be  done  "off-line",  that  is,  the  sorting  keys,  algoithms,  and 
formats  can  be  developed  in  advance  and  stored  in  the  computer. 
The  bulk  of  this  pre-and  post-decision  processing  can  therefore 
be  shifted  to  the  machine  and  the  human  processor  needs  to  assist 
only  on  an  exception  basis.  Note,  however,  that  this  also  shifts 
some  of  the  burden  to  the  message  originator  who  must  now  format 
or  otherwise  provide  sorting  keys. 

When  we  examine  the  last  five,  the  decision  processes 
themselves,  we  note  that  not  only  are  man’s  creative  talents 
required,  but  that  they  must  be  applied  on-line  as  the  informa¬ 
tion  is  being  processed.  On  the  other  hand,  the  computer 
provides  the  ideal  medium  to  be  used  as  a  memory  and  mind 
"extender"  in  support  of  the  decision  maker.  Not  only  can  it 
retrieve  any  data  item  in  memory,  but  it  can  display  it  in  what¬ 
ever  manner  the  decision  maker  desires,  it  can  operate  on  it 
according  to  instructions  to  perform  calculations  without  error, 
and,  finally,  it  can  accept  new  items  created  by  the  decision 
maker  as  he  develops  and  tests  alternative  hypotheses.  At  a 
still  higher  level  of  sophistication  it  can  store  and  retrieve 
both  enemy  and  friendly  behavior  patterns  --  just  a  bunch  of 
fancy  words  for  enemy  and  friendly  doctrine  —  to  still  further 
assist  the  decision  maker.  When  stored  in  the  computer  with 
tests  and  rules  for  their  application,  these  become  artificial 
intelligence,  put  at  the  disposal  of  the  decision  maker.  The 
result  of  this  combination  provides  a  tremendous  amount  of  lever¬ 
age  as  compared  to  the  decision  maker  trying  to  operate  with  the 
standard  "manual"  aids  consisting  of  manually  prepared  overlays 
and  displays,  and  oral  briefings.  Interactive,  man-machine  deci¬ 
sion  making  not  only  leads  to  faster  but  also  to  better  decision 
making  in  that  all  the  available  and  pertinent  data  can  be  ac¬ 
cessed  rapidly  and,  together,  man  and  machine  can  better  cope 


with  the  remaining  uncertainty 


The  above  discussion  has  demonstrated  that  automation 
can  help  achieve  the  basic  goals  for  the  tactical  Gr  system 
outlined  in  the  preceding  paragraphs.  It  has,  however,  also 
demonstrated  that  achieving  these  goals  may  not  be  quite  as 
simple  as  we  would  like  it  to  be.  Any  system  or  organization 
composed  of  men  and  machines  really  has  four  distinct  variables 
or  dimensions  which  can  be  manipulated  in  order  to  best  accom¬ 
plish  the  assigned  mission.  These  manipulable  variables  are: 
e  The  personnel  and  human  skills  available 

•  The  technological  "skills"  available 

e  The  breakdown  into  the  individual  tasks 

e  The  structure,  to  include  the  procedures  for 

accomplishing  the  tasks  required  by  the  mission 

These  four  variables  are  what  are  being  manipulated  in  any  endea¬ 
vor  to  improve  the  functioning  of  the  system.  Any  such  effort 
involves  a  whole  series  of  compromises  and  trade-offs  between  the 
capabilities  and  limitations  of  the  system  components.  Change 
any  one  of  these  variables;  for  example,  technology,  and  the 
compromises  previously  worked  out  may  no  longer  be  valid.  In 
general,  a  change  in  any  one  requires  changes  in  all  the  others 
in  order  to  exploit  the  potential  improvement  to  the  utmost. 
Think  of  the  profound  changes  in  personnel  skills,  task  assign¬ 
ment,  and  structure  introduced  into  military  forces  between  1918 
and  1939  by  the  introduction  of  |he  tank  and  the  tactical  radio. 
An  example  with  respect  to  the  C4  system  has  already  been  cited; 
automation  of  the  input/output  processes  alone  will  almost  imme¬ 
diately  overload  the  rest  of  the  depision  making  node.  One  must 
never  overlook  that  the  tactical  C4  system  is  a  system  and  that 
the  total  system  impact  on  any  change  must  be  considered .  The 
following  section  will  attempt  to  show  how  this  can  be  done. 

3.9  WHAT'S  AN  EXAMPLE  OF  AUTOMATION? 

The  preceding  paragraph  has  examined  the  potential 
impact  of  automation  on  the  individual  information  processes.  We 
need  to  develop  some  insights  as  to  the  potential  impacts  of 
automation  on  the  system  as  a  whole.  This  is  probably  best  done 
by  means  of  an  example. 

The  commander  has  expressed  the  desire  that  the  infor¬ 
mation  heretofore  provided  him  at  the  morning  and  evening  brief¬ 
ing  be  made  available  to  him  through  a  computer  terminal.  He  has 
also  seized  on  the  possibility  that  by  this  means  he  can,  in 
effect,  receive  as  much  as  he  wants  of  the  briefing  at  any  time 
without  waiting  for  the  schedule  briefing  time  and  the  informa¬ 
tion  provided  will  be  current,  i.e.,  represent  the  latest  staff 
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perceptions  and  recommendations,  whenever  he  requests  it. 
Surely,  this  would  be  the  epitome  of  the  continuing  estimate.  We 
need,  however,  a  method  for  assessing  the  impact  of  such  a  change 
on  the  entire  TOC  —  some  sort  of  global  representation  of  all 
the  TOC  operations  that  produce  the  twice  daily  briefings. 

The  general  model  of  all  of  the  tactical  information 
processes  shown  in  Figure  3-3  provides  the  building  blocks  for 
such  a  representation.  Each  staff  section  must  carry  out  all  of 
the  processing  shown  in  that  figure  because  many  decisions  are 
required  in  the  preparation  of  the  briefing:  Which  information 
should  be  presented?  What  additional  information  do  we  need? 
What  is  the  most  likely  interpretation  of  what  we  know?  What  are 
the  most  appropriate  courses  of  action?  What  recommendation 
should  we  make?  In  making  these  decisions,  each  staff  element  is 
determining  what  information  to  include  in  the  briefing  and, 
effectively,  creating  a  special  "briefing  data  base."  In  the 
manual  mode  this  briefing  data  base  consists  of  the  briefing 
maps,  overlays,  and  charts  plus  the  information  conveyed  to  the 
commander  from  the  memory  of  the  briefing  officer(s).  Such  a 
data  base  covers  the  entire  spectrum  of  the  operations  of  the 
command  as  a  whole,  but  will  be  less  detailed  than  the  processed 
(perceived)  data  bases  of  the  separate  staff  elements. 

Figure  3-7  illustrates  a  flow  chart  of  the  information 
processing  required  for  the  briefing  for  a  single  staff  element. 
Notice  that  the  lower  two  thirds  of  this  figure  is  identical  to 
Figure  3-3  and  represents  the  processing  needed  to  create  the 
staff  section's  own  perceived  data  base  --  its  working  files  and 
displays.  In  addition.  Figure  3-7  has  added  another  output  from 
the  staff  section  decisison  processes:  the  briefing  data  base. 
This  is,  in  turn,  accessed  by  the  commander's  decision  processes 
and  further  updated  to  reflect  his  decisions.  It  is  this  brief¬ 
ing  data  base  and  access  to  it  both  by  the  commander  and  staff 
that  we  are  proposing  to  automate.  It  must  be  noted  that  Figure 
3-7  shows  the  processing  of  only  a  single  staff  element,  in  this 
case  operations.  Each  of  the  other  coordinating  staff  sections 
and  special  staff  elements  must  go  through  the  same  series  of 
processes  (if  they  don’t  contribute  to  the  briefing  why  are  they 
in  the  TOC?)  .  Also  some  of  this  processing  may  go  on  at  loca¬ 
tions  other  than  the  TOC;  e.g.,  the  bulk  of  the  G-l  and  G-4 
sections  are  usually  at  Rear. 

Also  indicated  in  Figure  3-7  are  the  major  interfaces  or 
data  exchanges  that  need  to  take  place.  These  have  been  indi¬ 
cated  by  letters  A  through  G.  In  most  cases  these  take  place 
between  functions  and  data  bases  except  for  the  interface  between 
input/output  and  pre-  post-decision  processing  which  do  not  share 
a  common  data  base.  An  examination  of  the  changes  occurring  at 
these  interfaces  can  tell  us  a  lot  about  the  system  impact  of 
automating  portions  of  this  application. 


EXTERNAL  INFORMATION  STREAM 


Figure  3-7.  OPERATIONS  SECTION  PROCESSING 
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We  are  now  ready  to  examine  the  potential  impacts  of 
automating  the  briefing  data  base  on  the  rest  of  the  system. 

3.9.1  Changes  in  Processing  Load 

In  the  manual,  twice-daily  briefing  mode,  the  interface 
at  A  ( Comraander-Br ie f ing  Data  Base)  consists  of  two  discrete 
exchanges  per  day  between  the  commander  (commander  group)  and  the 
staff  briefers.  Let's  assume  in  our  hypothetical  staff  that 
these  occur  at  0630  and  1830.  Obviously,  the  staff  must  start 
building  its  briefing  data  base  some  time  prior  to  the  briefings. 
The  result  is  the  loading  of  the  staff  and  of  the  communication 
channels  which  looks  something  like  Figure  3-8.  Sometime  prior 
to  each  briefing  the  load  peaks,  usually  at  channel  capacity  (Did 
you  ever  try  to  get  a  "flash"  message  into  a  corps  TOC  about  30 
minutes  before  the  evening  briefing?). 

Now  let's  consider  what  is  likely  to  happen  if  we  imple¬ 
ment  the  commander's  desire  to  automate  the  briefing  data  base 
and  to  keep  it  continuously  current.  The  staff  will  now  be 
updating  the  briefing  data  base  (Interface  B  in  Figure  3-7)  as 
events  occur  and  interpretations  made.  The  commander  will  access 
these  data  and  staff  recommendations  and  enter  his  decisions 
through  Interface  A.  Because  the  staff  is  continuously  updating 
the  briefing  data  base  --  at  the  same  time  it  is  updating  its  own 
—  the  processing  load  will  be  spread  out  over  time  with  no  peaks 
induced  by  scheduled  briefing  times.  Both  commo  and  staff  activ¬ 
ity  will  tend  to  follow  much  more  closely  the  tempo  of  combat 
rather  than  an  artificially  imposed  briefing  schedule. 

3.9.2  Data  Base  and  Procedural  Changes 

The  fact  that  a  new  digital  data  base  must  be  con¬ 
structed  to  meet  the  commander's  briefing  needs  has  already  been 
alluded  to.  Just  what  will  be  in  this  data  base  and  how  compre¬ 
hensive  it  becomes  depends  largely  on  which  of  the  commander's 
decision  processes  it  is  designed  to  support.  Let's  examine  two 
extremes : 

•  Case  1 


The  commander  can  only  request  information 
that  has  already  been  interpreted,  validated, 
evaluated,  coordinated,  projected  and  extra¬ 
polated  by  the  staff.  He  can  evaluate  only 
alternatives  already  generated  by  the  staff 
and  the  computer  provides  no  help  in  their 
evaluation,  i.e.,  he  has  no  capability  to  use 
the  computer  to  generate  answers  to  "what  if" 
questions . 
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Figure  3  8  TOC  &  COMMO  ACTIVITY  RELATIVE  TO  BRIEFING  CYCLE 


Case  2 


At  the  other  extreme,  the  commander  has  the 
capability  of  conducting  a  dialog  with  the 
computer.  He  can  query  to  get  the  additional 
information  needed  for  his  personal  interpre¬ 
tation,  validation,  and  coordination  just  as 
he  might  during  repartee  at  the  briefing.  He 
can  ask  the  computer  to  project  current  trends 
and  to  make  extrapolations  as  to  likely  future 
situations.  He  can  enter  new  alternatives  not 
considered  by  the  staff  and  evaluate  the 
probable  outcome  of  various  alternatives  by 
obtaining  answers  to  various  "what  if"  ques¬ 
tions.  In  other  words  the  computer  support 
has  become  a  true  decision  aid. 

Now  let's  examine  the  impact  of  these  two  extremes  on 
the  operation  of  the  TOC.  For  Case  1  the  commander's  briefing 
data  base  will  be  a  compilation  of  relatively  small  subsets  of 
the  data  contained  in  the  various  staff  section  files.  The  only 
information  that  the  staff  sections  will  retrieve  from  the  brief¬ 
ing  data  base  will  be  any  decisions  entered  by  the  commander  and 
they  might  use  it  to  refresh  their  memories  as  to  "what  did  we 
last  tell  the  old  man?"  There  will  be  very  little  tendency  for 
the  staff  sections  to  view  the  briefing  data  base  as  being  in  any 
way  a  substitute  for  their  own  section  data  base.  The  operation 
continues  essentially  as  shown  in  Figure  3-7. 

For  Case  2  an  entirely  different  situation  will  prevail. 
The  briefing  data  base  will  tend  to  contain  more  and  more  Infor¬ 
mation  as  the  commander  probes  deeper  into  what  the  staff  is 
telling  him.  As  it  grows  the  staff  will  discover  how  much  faster 
and  easier  it  is  to  retrieve  the  information  they  need  for  their 
own  decision  processes  from  the  briefing  data  base  rather  than 
from  their  own  manual  files.  Also,  they  can  hardly  be  prevented 
(nor  should  they)  from  using  the  computer's  capability  to  answer 
"what  if"  questions  for  their  own  staff  decision  making.  The 
result  of  this  will  be  that  the  staff  will  ignore  its  manually 
maintained,  perceived  data  base  and  rely  more  and  more  on  what  is 
the,  now  automated,  briefing  data  base.  Figure  3-9  illustrates 
what  has  happened  and  shows  the  changes  that  have  taken  place  in 
the  original  TOC  operation  depicted  in  Figure  3-7.  The  separate 
staff  section  data  bases  have  completely  disappeared.  All  sec¬ 
tions  and  the  commander  now  rely  on  a  common  perceived  and  auto¬ 
mated  data  base.  Interface  B  ( STAFF- BRFG  Data  Base),  which 
previously  incorporated  the  transition  from  manual  to  digital 
data  i.~,  now  completely  digital;  interface  C  ( STAFF-Sect  j  on  Data 
Base)  has  disappeared  or  it  can  be  viewed  as  having  been  incor¬ 
porated  into  Interface  B.  The  transition  of  manual  to  digital 
has  now  shifted  to  Interface  D  (Pre-Post  Decision-Automated  Data 
Base).  All  of  the  staff  section  information  processing  above  the 
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Figure  3-9.  CASE  2  INFORMATION  PROCESSING 
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this  represents  a  major  change  in  the  TOC  operation  and  will 
require  very  careful  review  of  SOPs . 

It  should  be  noted  that  nothing  has  been  said  about  the 
physical  location  either  of  the  information  processes  or  of  the 
data  bases.  The  discussion  up  to  this  point  has  been  on  a  purely 
functional  basis.  The  third  potential  impact  of  the  computer  is 
on  the  location  of  TOC  activities  which  is  the  subject  of  the 
next  subparagraph. 

3.9.3  Dispersed  Operations 

The  third  major  potential  impact  of  computer  support  is 
on  the  location  of  the  various  TOC  activities.  The  ever  broad¬ 
ening  scope  of  the  battlefield,  both  in  terms  of  its  size  and  the 
variety  of  sensors  and  weapons  to  be  controlled  and  coordinated, 
coupled  with  the  ever  increasing  pace  of  modern  warfare  have 
caused  us  to  depend  on  larger  and  larger  amounts  of  data.  But  we 
still  have  the  same  human  limitations  on  the  number  of  different 
factors  that  we  can  juggle  simultaneously  in  making  tactical 
decisions.  We  must  depend  increasingly  on  memory  extenders 
(displays  and  files)  and  on  information  processing  by  others  to 
aggregate,  concentrate,  and  identify  and  key  factors  to  be  con¬ 
sidered  in  our  decision  making.  If  we  do  this  manually  we  are 
physically  tied  to  our  information  processing  system.  Staff 
sections  are  tied  to  their  manual  data  bases.  When  they  move  the 
data  base  deteriorates  rapidly  and  is  not  again  useable  until 
some  time  after  they  have  gone  back  on-line  and  begun  the  slow 
process  of  updating  it  by  hand.  It  takes  significant  time  inter¬ 
vals  to  transfer  current  data  from  Alternate  to  Main  and  vice 
verse  when  we  must  depend  on  voice  communication  channels  to  make 
the  transfer.  Similarly,  if  the  information  collected  and  pro¬ 
cessed  by  the  staff  is  presented  to  the  commander  by  means  of 
visual  displays  at  briefings,  all  must  be  collocated  —  usually 
in  the  vicinity  of  the  TOC.  For  much  the  same  reasons,  if  the 
separate  staff  section  data  bases  are  to  stay  coordinated  they 
must  also  be  collocated  —  again  in  the  TOC. 

Operating  in  the  mode  of  Figure  3-9  is,  however,  quite  a 
different  story.  Not  only  can  the  commander  be  located  remotely 
from  the  common  data  base  and  still  access  the  information  he 
needs  through  automated  interface  "A",  but  the  staff  sections  can 
also  be  separately  located  communicating  with  the  common  data 
base  through  automated  interfaces  "B-C"  and  "D".  Nor  need  the 
common  data  base,  shown  in  the  figure  as  a  single  functional 
entity,  be  all  in  one  place.  It,  too,  can  be  distributed  among 
several  locations  reducing  still  further  the  vulnerability  of  the 
TOC.  All  this  is  subject  to  two  caveats.  First,  the  physically 
separated  functional  components  and  data  bases  must  be  intercon¬ 
nected  with  a  network  of  digital  communication  which  can  also  be 
made  quite  resistant  to  enemy  interference  through  netting  and 
automatic  switching.  Second,  digital  communication  can  replace  a 
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major  fraction  of  current  voice  communication,  but  it  can  never 
replace  it  entirely.  Some  voice  communication  must  be  provided 
to  fill  the  very  human  need  for  human  interaction  in  times  of 
stress . 
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